Capítulo 23 Configuración de IKE (tareas)

En este capítulo se describe cómo configurar Internet Key Exchange (IKE) para sus sistemas. Una vez configurado IKE, se genera automáticamente material de claves para IPsec en la red. Este capítulo contiene la información siguiente:

• Configuración de IKE (mapa de tareas)

• Configuración de IKE con claves previamente compartidas (mapa de tareas)

• Configuración de IKE con certificados de clave pública (mapa de tareas)

• Configuración de IKE para sistemas portátiles (mapa de tareas)

• Configuración de IKE para buscar el hardware conectado (mapa de tareas)

• Cambio de los parámetros de transmisión de IKE (mapa de tareas)

Para obtener una descripción general sobre IKE, consulte el Capítulo 22Intercambio de claves de Internet (descripción general). Para obtener información de referencia sobre IKE, consulte el Capítulo 24Intercambio de claves de Internet (referencia). Para ver más procedimientos, consulte las secciones de ejemplos de las páginas del comando man ikeadm(1M), ikecert(1M) y ike.config(4).

Configuración de IKE (mapa de tareas)

Para autenticar IKE puede utilizar claves previamente compartidas, certificados autofirmados y certificados de una autoridad de certificación. Una regla vincula el método de autenticación de IKE específico con los puntos finales que se están protegiendo. Por tanto, puede utilizar uno o todos los métodos de autenticación de IKE de un sistema. Un puntero a una biblioteca PKCS #11 permite a los certificados utilizar un acelerador de hardware conectado.

Una vez configurado IKE, complete la tarea de IPsec que utilice la configuración de IKE. La tabla siguiente hace referencia a los mapas de tareas que se centran en una configuración de IKE específica.

Configuración de IKE con claves previamente compartidas (mapa de tareas)

En la tabla siguiente se incluyen los procedimientos para configurar y mantener IKE con claves previamente compartidas.

Configuración de IKE con claves previamente compartidas

Las claves previamente compartidas constituyen el método de autenticación más sencillo para IKE. Si esta configurando dos sistemas para que utilicen IKE y es el administrador de ambos sistemas, se recomienda utilizar claves previamente compartidas. Sin embargo, a diferencia de los certificados de clave pública, las claves previamente compartidas están vinculadas a direcciones IP específicas. Las claves previamente compartidas no se pueden utilizar con sistemas portátiles o sistemas cuya numeración podría variar. Además, al utilizar claves previamente compartidas, no es posible descargar los cálculos de IKE en el hardware conectado.

Cómo configurar IKE con claves previamente compartidas

La implementación de IKE ofrece algoritmos con claves cuya longitud varía. La longitud de claves que elija dependerá de la seguridad del sitio. En general, las claves largas son más seguras que las cortas.

Estos procedimientos utilizan los nombres de sistema enigma y partym. Sustituya los nombres de los sistemas con los nombres enigma y partym.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. En cada sistema, copie el archivo /etc/inet/ike/config.sample al archivo /etc/inet/ike/config.

3. Especifique las reglas y los parámetros generales en el archivo ike/config de cada sistema.

   Las reglas y los parámetros generales de este archivo deberían permitir la correcta aplicación de la directiva IPsec en el archivo ipsecinit.conf del sistema. Los siguientes ejemplos de ike/config funcionan con los ejemplos de ipsecinit.conf de Cómo proteger el tráfico entre dos sistemas con IPsec.

   1. Por ejemplo, modifique el archivo /etc/inet/ike/config del sistema enigma:

      ### 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 must be unique { 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 sha1 encr_alg aes } p2_pfs 5 }

      ---

      Nota –

      Todos los argumentos del parámetro auth_method deben encontrarse en la misma línea.

      ---

   2. Modifique el archivo /etc/inet/ike/config del sistema partym:

      ### 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 must be unique { 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 sha1 encr_alg aes } p2_pfs 5 }

4. En cada sistema, compruebe la sintaxis del archivo.

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

5. Genere números aleatorios para utilizar como material de claves.

   Si su sitio cuenta con un generador de números aleatorios, utilícelo. En un sistema Solaris, puede utilizar el comando od. Por ejemplo, el siguiente comando imprime dos líneas de números hexadecimales:

   % od -X -A n /dev/random | head -2 f47cb0f4 32e14480 951095f8 2b735ba8 0a9467d0 8f92c880 68b6a40e 0efe067d

   Para ver una explicación del comando od, consulte Cómo generar números aleatorios en un sistema Solaris y la página del comando man od(1).

   ---

   Nota –

   Otros sistemas operativos pueden requerir material de claves ASCII. Para generar una clave idéntica en los formatos hexadecimal y ASCII, consulte el Ejemplo 23–1.

   ---

6. Cree una clave a partir del resultado obtenido en el Paso 5.

   f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

   El algoritmo de autenticación de este procedimiento es SHA–1, tal como se muestra en el Paso 3. El tamaño del hash, es decir, el tamaño del resultado del algoritmo de autenticación, determina el tamaño mínimo recomendado de una clave previamente compartida. El resultado del algoritmo SHA–1 es 160 bits o 40 caracteres. La clave de ejemplo tiene una longitud de 56 caracteres, que proporciona material de claves adicional para usar en IKE.

7. Cree el archivo /etc/inet/secret/ike.preshared en cada sistema.

   Coloque la clave previamente compartida en cada archivo.

   1. Por ejemplo, en el sistema enigma, el archivo ike.preshared tendría el siguiente aspecto:

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

   2. En el sistema partym, el archivo ike.preshared tendría el siguiente aspecto:

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

   ---

   Nota –

   Las claves previamente compartidas de cada sistema deben ser idénticas.

   ---

Ejemplo 23–1 Generación de material de claves idéntico para dos sistemas con diferentes sistemas operativos

Solaris IPsec interopera con otros sistemas operativos. Si su sistema se comunica con un sistema que requiere claves previamente compartidas ASCII, debe generar una clave en dos formatos, hexadecimal y ASCII.

En este ejemplo, el administrador del sistema Solaris desea material de claves de 56 caracteres. El administrador utiliza el comando siguiente para generar una clave hexadecimal a partir de una contraseña ASCII. La opción -tx1 imprime los bytes uno a uno en todos los sistemas Solaris.

# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

Al eliminar los desfases y concatenar el resultado hexadecimal, la clave hexadecimal del sistema Solaris es 7061706965726d616368652077697468206361736865777320616e64. El administrador coloca este valor en el archivo ike.preshared del sistema Solaris.

# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

En el sistema que requiere claves previamente compartidas ASCII, la contraseña es la clave previamente compartida. El administrador del sistema Solaris comunica por teléfono la contraseña (papiermache with cashews and) al otro administrador.

Cómo actualizar las claves IKE previamente compartidas

Este procedimiento presupone que desea reemplazar una clave previamente compartida a intervalos regulares.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. Genere números aleatorios y cree una clave con la longitud adecuada.

   Para obtener más información, consulte Cómo generar números aleatorios en un sistema Solaris. Si va a generar una clave previamente compartida para un sistema Solaris que se comunica con un sistema operativo que requiere ASCII, consulte el Ejemplo 23–1.

3. Sustituya la clave actual por una nueva.

   Por ejemplo, en los hosts enigma y partym, debe reemplazar el valor de key en el archivo /etc/inet/secret/ike.preshared con un nuevo número que tenga la misma longitud.

4. Lea la nueva clave en el núcleo.

   • A partir de la versión Solaris 10 4/09, actualice el servicio ike.

     # svcadm refresh ike

   • Si está ejecutando una versión anterior a la Solaris 10 4/09, finalícela y reinicie el daemon in.iked.

     1. Compruebe el nivel de privilegio del daemon in.iked.

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

        Puede cambiar el material de claves si el comando devuelve un nivel de privilegio de 0x1 o 0x2. El nivel 0x0 no permite a las operaciones modificar ni ver el material de claves. De modo predeterminado, el daemon in.iked se ejecuta en el nivel de privilegio 0x0.

     2. Si el nivel de privilegio es 0x0, finalice el daemon y reinícielo.

        Al reiniciar el daemon, lee la nueva versión del archivo ike.preshared.

        # pkill in.iked # /usr/lib/inet/in.iked

     3. Si el nivel de privilegio es 0x1 o 0x2, lea la nueva versión del archivo ike.preshared.

        # ikeadm read preshared

Cómo ver las claves IKE previamente compartidas

Por defecto, el comando ikeadm impide que vea las teclas reales en un volcado de una fase 1 SA. La visualización de las claves es útil durante la depuración.

Para ver las teclas reales, debe aumentar el nivel de privilegios del daemon. Para obtener una descripción de los niveles de privilegios, consulte Comando de administración de IKE.

Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09 consulte Ejemplo 23–2.

Antes de empezar

IKE se configura y el servicio ike se ejecuta.

1. Consulte las teclas previamente compartidas de IKE.

   # ikeadm ikeadm> dump preshared

2. Si aparece un mensaje de error, aumente el nivel de privilegios del daemon in.iked .

   1. Aumente el nivel de privilegios del daemon in.iked en el repositorio SMF.

      # svcprop -p config/admin_privilege ike base # svccfg -s ike setprop config/admin_privilege=keymat

   2. Aumente el nivel de privilegios del daemon in.iked en ejecución.

      # svcadm refresh ike ; svcadm restart ike

   3. (Opcional) Confirme que el nivel de privilegios es keymat.

      # svcprop -p config/admin_privilege ike keymat

   4. Ejecute de nuevo el Paso 1 para ver las teclas.

3. Devuelva al daemon IKE el nivel de privilegios base.

   1. Después de ver las claves, devuelva al nivel de privilegios el valor predeterminado.

      # svccfg -s ike setprop config/admin_privilege=base

   2. Actualice y, a continuación, reinicie IKE.

      # svcadm refresh ike ; svcadm restart ike

Ejemplo 23–2 Verificación de las claves IKE compartidas previamente en una versión anterior a Solaris 10 4/09

En el siguiente ejemplo, el administrador está consultando claves en un sistema Solaris que no ejecuta la versión actual de Solaris. El administrador desea comprobar que las claves de este sistema son idénticas a las del sistema de comunicación. Después de comprobar que las claves de los dos sistemas son idénticos, el administrador restablece el nivel de privilegios a 0.

• En primer lugar, el administrador determina el nivel de privilegios del daemon in.iked.

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

• Debido a que el nivel de privilegios no es 0x1 o 0x2, el administrador detiene el daemon in.iked y, a continuación, aumenta el nivel de privilegios a 2.

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

• El administrador muestra las claves.

  adm1 # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (adm1). REMIP: AF_INET: port 0, 192.168.13.213 (com1).

• El administrador inicia sesión remota en el sistema de comunicación y determina que las claves sean idénticas.

• A continuación, el administrador restablece el nivel básico de privilegios.

  # ikeadm set priv base

Cómo agregar una clave IKE previamente compartida para una nueva entrada de directiva en ipsecinit.conf

Si agrega entradas de la directiva IPsec, mientras se ejecutan IPsec e IKE, deberá leer la nueva directiva y las reglas IKE en el núcleo. A partir de la versión Solaris 10 4/09, reinicie el servicio de directivas y actualice el servicio ike después de agregar las nuevas claves.

Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09, consulte el Ejemplo 23–3.

Antes de empezar

Este procedimiento presupone lo siguiente:

• El sistema enigma está configurado de acuerdo con lo descrito en Cómo configurar IKE con claves previamente compartidas.

• El sistema enigma va a proteger su tráfico con un nuevo sistema, ada.

• El daemon in.iked se ejecuta en ambos sistemas.

• Las interfaces de los sistemas se incluyen como entradas en el archivo /etc/hosts de ambos sistemas. La entrada siguiente es un ejemplo.

  192.168.15.7 ada 192.168.116.16 enigma

  Este procedimiento también funciona con una dirección IPv6 en el archivo /etc/inet/ipnodes. A partir de la versión Solaris 10 6/07 las entradas IPv6 se colocan en el archivo /etc/hosts.

• Ha agregado una nueva entrada de directiva en el archivo /etc/inet/ipsecinit.conf en ambos sistemas. Las entradas tienen el siguiente aspecto:

  # ipsecinit.conf file for enigma {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}

  # ipsecinit.conf file for ada {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

• En la versión actual, ha comprobado la sintaxis del archivo /etc/inet/ipsecinit.conf en ambos sistemas mediante lo siguiente:

  # ipsecconf -c -f /etc/inet/ipsecinit.conf

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. En este sistema, genere números aleatorios y cree una clave de entre 64 y 448 bits.

   Para obtener más información, consulte Cómo generar números aleatorios en un sistema Solaris. Si va a generar una clave previamente compartida para un sistema Solaris que se comunica con un sistema operativo que requiere ASCII, consulte el Ejemplo 23–1.

3. Envíe la clave al administrador del sistema remoto.

   Ambos deben agregar la misma clave previamente compartida y de forma simultánea. La seguridad de su clave depende de la seguridad de su mecanismo de transmisión. Se recomienda un mecanismo fuera de banda, como un correo registrado o un fax protegido. También puede utilizar una sesión ssh para administrar ambos sistemas.

4. Cree una regla para que IKE administre las claves para enigma y ada.

   1. En el sistema enigma, agregue la regla siguiente al archivo /etc/inet/ike/config:

      ### 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 sha1 encr_alg blowfish} p2_pfs 5 }

   2. En el sistema ada, agregue la siguiente regla:

      ### 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 sha1 encr_alg blowfish} p2_pfs 5 }

5. Asegúrese de que haya claves IKE previamente compartidas al iniciar.

   1. En el sistema enigma, agregue la siguiente información al archivo /etc/inet/secret/ike.preshared:

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

   2. En el sistema ada, agregue la información siguiente al archivo ike.preshared:

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

6. En cada sistema, reinicie el servicio de directivas de IPsec para asegurar la interfaz agregada.

   # svcadm restart policy

7. En cada sistema, actualice el servicio ike.

   # svcadm refresh ike

8. Compruebe que los sistemas se puedan comunicar.

   Consulte Verificación de que las claves IKE previamente compartidas sean idénticas.

Ejemplo 23–3 Adición de una clave IKE compartida previamente para una nueva entrada de directiva IPsec

En el siguiente ejemplo, el administrador agrega una clave compartida previamente a un sistema Solaris que no ejecuta la versión actual de Solaris. El administrador sigue el procedimiento anterior para modificar los archivos ike/config e ike., así como generar las claves y establecer contacto con el sistema remoto. El administrador utiliza comandos diferentes para leer la nueva directiva IPsec y las reglas IKE en el núcleo.

• Antes de generar la nueva tecla, el administrador define el nivel de privilegios del daemon in.iked en 2.

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

• Después de enviar la tecla para el otro sistema y agregar la nueva tecla al sistema, el administrador reduce el nivel de privilegios.

  # ikeadm set priv base

• A continuación, el administrador lee la nueva directiva IPsec en el núcleo.

  # ipsecconf -a /etc/inet/ipsecinit.conf

• Por último, el administrador lee las nuevas reglas IKE en el núcleo.

  # ikeadm read rules

Verificación de que las claves IKE previamente compartidas sean idénticas

Si las claves previamente compartidas de los sistemas que se comunican no son idénticas, los sistemas no se podrán autenticar.

Antes de empezar

IPsec se ha configurado y se ha habilitado entre los dos sistemas que se están probando. Se está ejecutando la versión Solaris 10 actual.

Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09 consulte Ejemplo 23–2.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. En cada sistema, compruebe el nivel de privilegios del daemon in.iked.

   # svcprop -p config/admin_privilege ike base

   • Si el nivel de privilegios es keymat, continúe con el Paso 3.

   • Si el nivel de privilegios es base o modkeys, aumente su nivel.

     A continuación, actualice el servicio ike y reinícielo.

     # svccfg -s ike setprop config/admin_privilege=keymat # svcadm refresh ike ; svcadm restart ike # svcprop -p config/admin_privilege ike keymat

3. En cada sistema, visualice la información de claves previamente compartidas.

   # 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 los dos vaciados.

   Si las claves previamente compartidas no son idénticas, sustituya una de ellas con la otra en el archivo /etc/inet/secret/ike.preshared.

5. Cuando se haya completado la verificación, devuelva al nivel de privilegios el valor predeterminado de cada sistema.

   # svccfg -s ike setprop config/admin_privilege=base # svcadm restart ike

Configuración de IKE con certificados de clave pública (mapa de tareas)

La tabla siguiente incluye los procedimientos para crear certificados de clave pública para IKE. Entre estos procedimientos se incluye cómo acelerar y guardar los certificados en el hardware conectado.

Configuración de IKE con certificados de clave pública

Los certificados de clave pública acaban con la necesidad de que los sistemas que se comunican compartan material de claves secreto fuera de banda. A diferencia de las claves previamente compartidas, un certificado de clave pública se puede utilizar en un equipo portátil o en un sistema cuya numeración podría cambiar.

Los certificados de clave pública también podrían guardarse en el hardware conectado. Para conocer el procedimiento, consulte Configuración de IKE para buscar el hardware conectado (mapa de tareas).

Cómo configurar IKE con certificados de clave pública autofirmados

Los certificados autofirmados requieren menos carga que los certificados públicos de una autoridad de certificación, pero no se escalan fácilmente.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. Agregue un certificado autofirmado a la base de datos ike.privatekeys.

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

   -ks

   Crea un certificado autofirmado.

   -kc

   Crea una solicitud de certificado. Para conocer el procedimiento, consulte Cómo configurar IKE con certificados firmados por una autoridad de certificación.

   -m tamaño_clave

   Es el tamaño de la clave. Tamaño_clave puede ser 512, 1024, 2048, 3072 o 4096.

   -t tipo_clave

   Especifica el tipo de algoritmo que utilizar. Tipo_algoritmo puede ser rsa-sha1, rsa-md5 o dsa-sha1.

   -D nombre_d

   Es el nombre X.509 distinguido para el tema del certificado. Nombre_d suele tener el formato siguiente: C=country (país), O=organization (organización=, OU=organizational unit (unidad organizativa), CN=common name (nombre común). Las etiquetas válidas son C, O, OU y CN.

   -A nombre_alt

   Nombre alternativo del certificado. Nombre_alt tiene el formato tag=value. Las etiquetas válidas son IP, DNS, email y DN.

   -S tiempo_inicio_validez

   Proporciona un tiempo de inicio de validez absoluto o relativo para el certificado.

   -F tiempo_fin_validez

   Proporciona un tiempo de fin de validez absoluto o relativo para el certificado.

   -T ID_token

   Permite al token de hardware PKCS #11 generar las claves. Los certificados se guardan en el hardware.

   1. Por ejemplo, el comando del sistema partym sería como el siguiente:

      # 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. El comando del sistema enigma sería como el siguiente:

      # 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. Guarde el certificado y envíelo al sistema remoto.

   El certificado se puede pegar en un mensaje de correo electrónico.

   1. Por ejemplo, enviaría el siguiente certificado de partym al administrador de enigma:

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

   2. El administrador de enigma enviaría el siguiente certificado de enigma:

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

4. En cada sistema, agregue el certificado que reciba.

   1. Copie la clave pública del correo electrónico del administrador.

   2. Escriba el comando ikecert certdb -a y pulse la tecla Intro.

      Al pulsar Intro no aparecerá ningún mensaje.

      # ikecert certdb -a Press the Return key

   3. Pegue la clave pública. A continuación, pulse la tecla Intro. Para finalizar la entrada, pulse Control+D.

      -----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key <Control>-D

5. Verifique con el otro administrador que el certificado proceda de dicho administrador.

   Por ejemplo, puede llamar por teléfono al otro administrador para comparar los valores de hash de clave pública. El hash de clave pública del certificado compartido debe ser idéntico en los dos sistemas.

   1. Enumere el certificado guardado en su sistema.

      Por ejemplo, en el sistema partym, el certificado público se encuentra en la ranura 1 y el certificado privado se encuentra en la ranura 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 este valor con el hash de clave pública del sistema enigma.

      El hash de clave pública se puede comunicar por teléfono.

      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

6. En cada sistema, confíe en ambos certificados.

   Edite el archivo /etc/inet/ike/config para reconocer los certificados.

   El administrador del sistema remoto proporciona los valores para los parámetros cert_trust, remote_addr y remote_id.

   1. Por ejemplo, en el sistema partym, el archivo ike/config tendría el siguiente aspecto:

      # 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 telephone 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 sha1 encr_alg aes} }

   2. En el sistema enigma, agregue los valores de enigma para los parámetros locales en el archivo ike/config.

      Para los parámetros remotos, utilice los valores de partym. Asegúrese de que el valor de la palabra clave label sea único. Este valor debe ser diferente del valor label del sistema remoto.

      … { 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 …

Ejemplo 23–4 Verificación de la validez de un certificado procedente de otro administrador

En este ejemplo, los administradores recurren al nombre del asunto para verificar que los certificados sean idénticos.

El primer administrador guarda la salida de la generación y hace constar el certificado en un archivo. Debido a que la salida del comando ikecert imprime un error estándar, el administrador redirige el error estándar al archivo.

sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

El administrador verifica el contenido del archivo.

sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

A continuación, el administrador envía el archivo al segundo administrador por correo electrónico.

El segundo administrador coloca el archivo en un directorio seguro e importa el certificado del archivo.

sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

El comando ikecert importa únicamente el texto que hay entre las líneas -----BEGIN y -----END. El administrador verifica que el certificado local tenga el mismo valor hash de clave pública quel valor hash de clave pública que haya en el archivo co2sys.

sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Para asegurarse de que el primer administrador envíe este correo electrónico, el segundo administrador telefonea al primero para verificar el nombre del asunto del certificado.

Ejemplo 23–5 Especificación de un tiempo de inicio y un tiempo de fin para un certificado

En este ejemplo, el administrador del sistema partym establece las fechas durante las cuales el certificado es válido. El certificado será anterior en dos días y medio, y será válido para 4 años y 6 meses a partir de la fecha de creación.

# 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

El administrador del sistema enigma establece las fechas para la validez del certificado. El certificado será anterior en dos días y será válido hasta las 12 de la noche del 31 de diciembre de 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"

Cómo configurar IKE con certificados firmados por una autoridad de certificación

Los certificados públicos de una autoridad de certificación requieren negociar con una organización externa. Los certificados se pueden escalar con gran facilidad para proteger un mayor número de sistemas que se comunican.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. Utilice el comando ikecert certlocal -kc para crear una solicitud de certificado.

   Para ver una descripción de los argumentos del comando, consulte el Paso 2 en Cómo configurar IKE con certificados de clave pública autofirmados.

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

   1. Por ejemplo, el comando siguiente crea una solicitud de certificado en el sistema partym:

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

   2. El comando siguiente crea una solicitud de certificado en el sistema enigma:

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

3. Envíe la solicitud de certificado a una organización de PKI.

   La organización de PKI puede indicar cómo enviar la solicitud de certificado. La mayoría de las organizaciones cuenta con un sitio web con un formulario de envío. El formulario requiere una prueba de que el envío es legítimo. Normalmente, la solicitud de certificado se pega en el formulario. Cuando la organización ha comprobado la solicitud, emite los dos objetos de certificado siguientes y una lista de los certificados revocados:

   • El certificado de clave pública: este certificado se basa en la solicitud que ha enviado a la organización. La solicitud que envía forma parte del certificado de clave pública. El certificado le identifica de forma exclusiva.

   • Una autoridad de certificación: la firma de la organización. La autoridad de certificación verifica que el certificado de clave pública sea legítimo.

   • Una lista de revocación de certificados (CRL): La lista de certificados más reciente que ha revocado la organización. La CRL no se envía por separado como objeto de certificado si el acceso a la CRL está integrado en el certificado de clave pública.

     Cuando un URI para la CRL está integrado en el certificado de clave pública, IKE puede recuperar automáticamente la CRL. De modo similar, cuando una entrada DN (nombre de directorio en servidor LDAP) se integra en el certificado de clave pública, IKE puede recuperar la CRL y almacenarla en caché desde un servidor LDAP que se especifique.

     Consulte Cómo administrar una lista de revocación de certificados para ver un ejemplo de URI integrado y una entrada DN integrada en un certificado de clave pública.

4. Agregue cada certificado al sistema.

   La opción -a de ikecert certdb -a agrega el objeto pegado a la base de datos de certificados pertinente del sistema. Para más información, consulte IKE con certificados de claves públicas.

   1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   2. Agregue el certificado de clave pública que ha recibido de la organización de PKI.

      # ikecert certdb -a Press the Return key Paste the certificate: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D

   3. Agregue la autoridad de certificación de la organización de PKI.

      # ikecert certdb -a Press the Return key Paste the CA: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D

   4. Si la organización de PKI ha enviado una lista de certificados revocados, agregue la CRL a la base de datos certrldb:

      # ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D

5. Utilice la palabra clave cert_root para identificar la organización de PKI en el archivo /etc/inet/ike/config.

   Utilice el nombre que proporciona la organización de PKI.

   1. Por ejemplo, el archivo ike/config del sistema partym podría ser similar a:

      # 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_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

      ---

      Nota –

      Todos los argumentos del parámetro auth_method deben encontrarse en la misma línea.

      ---

   2. En el sistema enigma, cree un archivo similar.

      En concreto, el archivo enigma ike/config llevará a cabo las siguientes acciones:

      • Incluirá el mismo valor de cert_root.

      • Utilizará los valores de enigma para los parámetros locales.

      • Utilice los valores de partym para los parámetros remotos.

      • Cree un valor único para la palabra clave label. Este valor debe ser diferente del valor label del sistema remoto.

      … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" … { 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 …

6. Indique a IKE cómo administrar las CRL.

   Elija la opción adecuada:

   • Ninguna CRL disponible

     Si la organización de PKI no proporciona ninguna CRL, agregue la palabra clave ignore_crls al archivo ike/config.

     # Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls …

     La palabra clave ignore_crls indica a IKE que no debe buscar ninguna CRL.

   • CRL disponible

     Si la organización de PKI proporciona un punto de distribución central para las CRL, puede modificar el archivo ike/config para que haga referencia a esa ubicación.

     Consulte Cómo administrar una lista de revocación de certificados para ver algunos ejemplos.

Ejemplo 23–6 Uso de rsa_encrypt durante la configuración de IKE

Cuando utiliza auth_method rsa_encrypt en el archivo ike/config, debe agregar el certificado equivalente a la base de datos publickeys.

1. Envíe el certificado al administrador del sistema remoto.

   El certificado se puede pegar en un mensaje de correo electrónico.

   Por ejemplo, el administrador de partym enviaría el siguiente mensaje de correo electrónico:

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

   El administrador de enigma enviaría el siguiente mensaje de correo electrónico:

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

2. En cada sistema, agregue el certificado enviado por correo electrónico a la base de datos publickeys local.

   # ikecert certdb -a Press the Return key -----BEGIN X509 CERTIFICATE----- MII… -----END X509 CERTIFICATE----- Press the Return key <Control>-D

El método de autenticación para el cifrado de RSA oculta las identidades de IKE de los intrusos. Dado que el método rsa_encrypt oculta la identidad del equivalente, IKE no puede recuperar su certificado. Como consecuencia de ello, el método rsa_encrypt requiere que los equivalentes de IKE conozcan las claves públicas el uno del otro.

Por tanto, si utiliza un auth_method de rsa_encrypt en el archivo /etc/inet/ike/config, debe agregar el certificado del equivalente a la base de datos publickeys. La base de datos publickeys incluye tres certificados para cada par de sistemas que se comunican:

• Su certificado de clave pública

• El certificado de la administración de certificación

• El certificado de clave pública del equivalente

Resolución de problemas: La carga útil de IKE, que incluye los tres certificados, puede ser demasiado grande para que la cifre rsa_encrypt. Errores como un fallo de autenticación o una carga útil mal formada pueden indicar que el método rsa_encrypt no puede cifrar la carga útil total. Reduzca el tamaño de la carga útil utilizando un método que requiera únicamente dos certificados, por ejemplo rsa_sig.

Cómo generar y almacenar certificados de clave pública en el hardware

La generación y el almacenamiento de certificados de clave pública en hardware es similar a la generación y el almacenamiento de certificados de clave pública en el sistema. En el hardware, los comandos ikecert certlocal e ikecert certdb deben identificar el hardware. La opción -T con el ID de símbolo identifica el hardware para los comandos.

Antes de empezar

• El hardware debe estar configurado.

• El hardware utiliza la biblioteca /usr/lib/libpkcs11.so, a menos que la palabra clave pkcs11_path del archivo /etc/inet/ike/config haga referencia a una biblioteca distinta. La biblioteca debe implementarse de acuerdo con el estándar siguiente: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), es decir, una biblioteca PKCS #11.

  Consulte Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 4000 para obtener instrucciones sobre la instalación.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. Genere un certificado autofirmado o una solicitud de certificado y especifique el ID de símbolo.

   Elija una de las siguientes opciones:

   ---

   Nota –

   La placa Sun Crypto Accelerator 4000 admite claves de hasta 2048 bits para RSA. Para DSA, esta placa admite claves de hasta 1024 bits.

   ---

   • Para un certificado autofirmado, utilice esta sintaxis.

     # ikecert certlocal -ks -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password

     El argumento para la opción -T es el ID de símbolo de la placa Sun Crypto Accelerator 4000 conectada.

   • Para obtener una solicitud de certificado, utilice esta sintaxis.

     # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password

   Para ver una descripción de los argumentos para el comando ikecert, consulte la página del comando man ikecert(1M).

3. Cuando se le solicite un PIN, escriba el usuario de Sun Crypto Accelerator 4000, dos puntos y la contraseña del usuario.

   Si la placa de Sun Crypto Accelerator 4000 tiene un usuario ikemgr cuya contraseña es rgm4tigt, debe escribir:

   Enter PIN for PKCS#11 token: ikemgr:rgm4tigt

   ---

   Nota –

   La respuesta de PIN se guarda en el disco como texto sin cifrar.

   ---

   Una vez indicada la contraseña, se imprime el certificado:

   Enter PIN for PKCS#11 token: ikemgr:rgm4tigt -----BEGIN X509 CERTIFICATE----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … oKUDBbZ9O/pLWYGr -----END X509 CERTIFICATE-----

4. Envíe su certificado para que lo pueda utilizar la otra parte.

   Elija una de las siguientes opciones:

   • Envíe el certificado autofirmado al sistema remoto.

     El certificado se puede pegar en un mensaje de correo electrónico.

   • Envíe la solicitud de certificado a una organización que administre PKI.

     Siga las instrucciones de la administración de PKI para enviar la solicitud de certificado. Para obtener información más detallada, consulte el Paso 3 de Cómo configurar IKE con certificados firmados por una autoridad de certificación.

5. En el sistema, edite el archivo /etc/inet/ike/config para que reconozca los certificados.

   Elija una de las siguientes opciones.

   • Certificado autofirmado

     Utilice los valores que proporciona el administrador del sistema remoto para los parámetros cert_trust, remote_id y remote_addr. Por ejemplo, en el sistema enigma, el archivo ike/config sería similar a:

     # 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 Subject Alt Name cert_trust "192.168.13.213" Remote system's certificate Subject Alt name # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { 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_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

   • Solicitud de certificado

     Escriba el nombre que proporciona la organización de PKI como valor para la palabra clave cert_root. Por ejemplo, el archivo ike/config del sistema enigma podría ser similar a:

     # 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" # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { 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_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

6. Coloque los certificados de la otra parte en el hardware.

   Responda a la solicitud de PIN del mismo modo que en el Paso 3.

   ---

   Nota –

   Debe agregar los certificados de clave pública al mismo hardware conectado que generó la clave privada.

   ---

   • Certificado autofirmado.

     Agregue el certificado autofirmado al sistema remoto. En este ejemplo, el certificado se guarda en el archivo, DCA.ACCEL.STOR.CERT.

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password

     Si el certificado autofirmado utilizó rsa_encrypt como valor para el parámetro auth_method, agregue el certificado del equivalente al hardware.

   • Certificados de una organización de PKI.

     Agregue el certificado que ha generado la organización a partir de la solicitud de certificado, y agregue la autoridad de certificación.

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT Enter PIN for PKCS#11 token: Type user:password

     Para agregar una lista de revocación de certificados (CRL) de la organización de PKI, consulte Cómo administrar una lista de revocación de certificados.

Cómo administrar una lista de revocación de certificados

Una lista de revocación de certificados (CRL) contiene certificados caducados o que suponen un peligro de una autoridad de certificación. Existen cuatro modos de administrar las CRL.

• Debe indicar a IKE que omita las CRL si la organización de la autoridad de certificación no emite ninguna CRL. Esta opción se muestra en el Paso 6 en Cómo configurar IKE con certificados firmados por una autoridad de certificación.

• Puede indicar a IKE que acceda a las CRL desde un indicador de recursos uniforme (URI) cuya dirección esté integrada en el certificado de clave pública de la autoridad de certificación.

• Puede indicar a IKE que acceda a las CRL desde un servidor LDAP cuya entrada de nombre de directorio (DN) esté integrada en el certificado de clave pública de la autoridad de certificación.

• Puede proporcionar la CRL como argumento para el comando ikecert certrldb. Si desea ver un ejemplo, consulte el Ejemplo 23–7.

El siguiente procedimiento describe cómo indicar a IKE que utilice las CRL de un punto de distribución central.

1. Visualice el certificado que ha recibido de la autoridad de certificación.

   # ikecert certdb -lv certspec

   -l

   Enumera los certificados de la base de datos IKE.

   -v

   Enumera los certificados en modo detallado. Utilice esta opción con precaución.

   certspec

   Es un patrón que coincide con un certificado de la base de datos de certificados IKE.

   Por ejemplo, el certificado siguiente ha sido emitido por Sun Microsystems. Los detalles se han modificado.

   # 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

   Observe la entrada CRL Distribution Points. La entrada URI indica que la CRL de esta organización está disponible en Internet. La entrada DN indica que la CRL está disponible en un servidor LDAP. Cuando IKE accede a la CRL, ésta se almacena en caché para futuros usos.

   Para acceder a la CRL, debe alcanzar un punto de distribución.

2. Elija uno de los métodos siguientes para acceder a la CRL desde un punto de distribución central.

   • Utilice el URI.

     Agregue la palabra clave use_http al archivo /etc/inet/ike/config del host. Por ejemplo, el archivo ike/config tendría el siguiente aspecto:

     # Use CRL from organization's URI use_http …

   • Utilice un proxy Web.

     Agregue la palabra clave proxy al archivo ike/config. La palabra clave proxy adopta una dirección URL como argumento, como en el caso siguiente:

     # Use own web proxy proxy "http://proxy1:8080"

   • Utilice un servidor LDAP.

     Configure el servidor LDAP como argumento para la palabra clave ldap-list del archivo /etc/inet/ike/config del host. Su organización proporciona el nombre del servidor LDAP. La entrada del archivo ike/config tendría el siguiente aspecto:

     # Use CRL from organization's LDAP ldap-list "ldap1.sun.com:389,ldap2.sun.com" …

   IKE recupera la CRL y almacena en caché la CRL hasta que caduque el certificado.

Ejemplo 23–7 Cómo pegar una CRL en la base de datos certrldb local

Si la CRL de la organización de PKI no está disponible en un punto de distribución central, puede agregar la CRL manualmente a la base de datos certrldb local. Siga las instrucciones de la organización de PKI para extraer la CRL en un archivo y, a continuación, agregue la CRL a la base de datos con el comando ikecert certrldb -a.

# ikecert certrldb -a < Sun.Cert.CRL

Configuración de IKE para sistemas portátiles (mapa de tareas)

La tabla siguiente incluye los procedimientos para configurar IKE para la administración de sistemas que se registran remotamente en un sitio central.

Configuración de IKE para sistemas portátiles

Cuando se configuran correctamente, las oficinas domésticas y los portátiles pueden utilizar IPsec e IKE para comunicarse con los equipos centrales de la compañía. Una directiva IPsec general que se combina con un método de autenticación de claves públicas permite a los sistemas remotos proteger su tráfico en un sistema central.

Cómo configurar IKE para sistemas remotos

IPsec e IKE requieren un ID único para identificar el origen y el destino. Para los sistemas remotos o portátiles que no tienen una dirección IP única, debe utilizar otro tipo de ID. Los tipos de ID como DNS, DN o email se pueden utilizar para identificar a un sistema de forma exclusiva.

Los sistemas remotos o portátiles que tienen direcciones IP exclusivas se siguen configurando mejor con un tipo de ID diferente. Por ejemplo, si los sistemas intentan conectarse a un sitio central desde un enrutador NAT, no se utilizarán sus direcciones exclusivas. Un enrutador NAT asigna una dirección IP arbitraria, que el sistema central no reconocería.

Las claves previamente compartidas tampoco funcionan bien como mecanismo de autenticación para sistemas portátiles, dado que requieren direcciones IP fijas. Los certificados autofirmados o certificados desde un PKI permiten a los sistemas portátiles comunicarse con el sitio central.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. Configure el sistema central para que reconozca los sistemas portátiles.

   1. Configure el archivo /etc/hosts.

      El sistema central no tiene que reconocer las direcciones específicas para los sistemas portátiles.

      # /etc/hosts on central central 192.xxx.xxx.x

   2. Configure el archivo ipsecinit.conf.

      El sistema central necesita una directiva que permite una amplia gama de direcciones IP. Los certificados de la directiva IKE garantizan que los sistemas conectados son legítimos.

      # /etc/inet/ipsecinit.conf on central # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   3. Configure el archivo ike.config.

      DNS identifica el sistema central. Se utilizan certificados para autenticar el sistema.

      ## /etc/inet/ike/ike.config on central # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # List self-signed certificates - trust server and enumerated others #cert_trust "DNS=central.domain.org" #cert_trust "DNS=mobile.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=root@central.domain.org" #cert_trust "email=user1@mobile.domain.org" # # Rule for mobile systems with certificate { label "Mobile systems with certificate" local_id_type DNS # Any mobile system who knows my DNS or IP can find me. local_id "central.domain.org" local_addr 192.xxx.xxx.x # Root certificate ensures trust, # so allow any remote_id and any remote IP address. remote_id "" remote_addr 0.0.0.0/0 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } }

3. Inicie sesión en cada sistema portátil y configure el sistema para buscar el sistema central.

   1. Configure el archivo /etc/hosts.

      El archivo /etc/hosts no necesita una dirección para el sistema portátil, pero puede proporcionar una. El archivo debe contener una dirección IP pública para el sistema central.

      # /etc/hosts on mobile mobile 10.x.x.xx central 192.xxx.xxx.x

   2. Configure el archivo ipsecinit.conf.

      El sistema portátil debe encontrar el sistema central por su dirección IP pública. Los sistemas deben configurar la misma directiva IPsec.

      # /etc/inet/ipsecinit.conf on mobile # Find central {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   3. Configure el archivo ike.config.

      El identificador no puede ser una dirección IP. Los siguientes identificadores son válidos para sistemas portátiles:

      • DN=nombre_directorio_ldap

      • DNS=dirección_servidor_nombre_dominio

      • email=dirección_correo_electrónico

      Se utilizan certificados para autenticar el sistema portátil.

      ## /etc/inet/ike/ike.config on mobile # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # Self-signed certificates - trust me and enumerated others #cert_trust "DNS=mobile.domain.org" #cert_trust "DNS=central.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=user1@domain.org" #cert_trust "email=root@central.domain.org" # # Rule for off-site systems with root certificate { label "Off-site mobile with certificate" local_id_type DNS # NAT-T can translate local_addr into any public IP address # central knows me by my DNS local_id "mobile.domain.org" local_addr 0.0.0.0/0 # Find central and trust the root certificate remote_id "central.domain.org" remote_addr 192.xxx.xxx.x p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } }

4. Lea la configuración de IKE en el núcleo.

   • A partir de la versión Solaris 10 4/09, habilite el servicio ike.

     # svcadm enable svc:/network/ipsec/ike

   • Si está ejecutando una versión anterior a la Solaris 10 4/09, reinicie el sistema.

     # init 6

     También puede detener e iniciar el daemon in.iked.

Ejemplo 23–8 Configuración de un equipo para que acepte tráfico IPsec de un sistema portátil

IKE puede iniciar negociaciones desde un enrutador NAT. Sin embargo, la configuración de IKE ideal no incluye un enrutador NAT. En el ejemplo siguiente, una autoridad de certificación ha emitido certificados raíz. Los certificados de la autoridad de certificación se colocan en el sistema portátil y el sistema central. Un sistema central acepta las negociaciones de IPsec desde un sistema con un enrutador NAT. main1 es el sistema de la compañía que puede aceptar conexiones desde sistemas remotos. Para configurar los sistemas remotos, consulte el Ejemplo 23–9.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
}

Ejemplo 23–9 Configuración de un sistema con una NAT con IPsec

En el ejemplo siguiente, una autoridad de certificación ha emitido certificados raíz y los ha colocado en el sistema portátil y el sistema central. mobile1 se conecta a la oficina central de la compañía desde casa. La red del proveedor de servicios de Internet (ISP) utiliza un enrutador NAT para permitir al ISP asignar a mobile1 una dirección privada. A continuación, el enrutador convierte la dirección privada en una dirección IP pública que comparte con otros nodos de red del ISP. La oficina central de la compañía no está detrás de un dispositivo NAT. Para configurar el sistema en las oficinas de la empresa, consulte el Ejemplo 23–8.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Ejemplo 23–10 Aceptación de certificados autofirmados de un sistema portátil

En el ejemplo siguiente, se han emitido certificados autofirmados y se encuentran en el sistema portátil y el sistema central. main1 es el sistema de la compañía que puede aceptar conexiones desde sistemas remotos. Para configurar los sistemas que no estén en las oficinas, consulte el Ejemplo 23–11.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Ejemplo 23–11 Uso de certificados autofirmados para contactar con un sistema central

En el ejemplo siguiente, mobile1 se conecta a la oficina central de la compañía desde casa. Los certificados se han emitido y se colocan en el sistema portátil y el sistema central. La red ISP utiliza un enrutador NAT para permitir al ISP asignar a mobile1 una dirección privada. A continuación, el enrutador convierte la dirección privada en una dirección IP pública que comparte con otros nodos de red del ISP. La oficina central de la compañía no está detrás de un dispositivo NAT. Para configurar el sistema en las oficinas de la empresa, consulte el Ejemplo 23–10.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Configuración de IKE para buscar el hardware conectado (mapa de tareas)

La tabla siguiente incluye los procedimientos que indican a IKE el hardware conectado. Debe informar a IKE del hardware conectado para que pueda utilizarlo. Para utilizar el hardware, siga los procedimientos de Configuración de IKE con certificados de clave pública .

No tiene que informar a IKE sobre el hardware en chip. Por ejemplo, el procesador UltraSPARC® T2 proporciona aceleración criptográfica. No es necesario configurar IKE para encontrar los aceleradores en chip.

Configuración de IKE para buscar el hardware conectado

Los certificados de claves públicas también se pueden almacenar en el hardware adjunto. La placa Sun Crypto Accelerator 1000 sólo proporciona almacenamiento. Las placas Sun Crypto Accelerator 4000 y Crypto Accelerator 6000 de Sun proporcionan almacenamiento y permiten que se descarguen operaciones de claves públicas desde el sistema a la placa.

Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 1000

Antes de empezar

El procedimiento siguiente presupone que hay una placa de Sun Crypto Accelerator 1000 conectada al sistema. Además, el procedimiento presupone que se ha instalado y configurado el software para la placa. Para obtener instrucciones, consulte Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. Compruebe que esté vinculada la biblioteca de PKCS #11.

   Escriba el comando siguiente para determinar si la biblioteca de PKCS #11 está vinculada:

   # 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 /usr/lib/libpkcs11.so #

3. Solaris 10 1/06: A partir de esta versión, puede guardar las claves en el almacén de claves softtoken.

   Para obtener información sobre el almacén de claves que proporciona la estructura criptográfica de Solaris, consulte la página del comando man cryptoadm(1M) Si desea ver un ejemplo del uso del almacén de claves, consulte el Example 23–12.

Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 4000

Antes de empezar

El siguiente procedimiento presupone que hay una placa de Sun Crypto Accelerator 4000 conectada al sistema. Además, el procedimiento presupone que se ha instalado y configurado el software para la placa. Para obtener instrucciones, consulte la Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide.

Si utiliza una placa Crypto Accelerator 6000 de Sun, consulte la Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide para obtener instrucciones.

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. Compruebe que esté vinculada la biblioteca de PKCS #11.

   IKE utiliza las rutinas de la biblioteca para administrar la generación de claves y el almacenamiento de claves en la placa de Sun Crypto Accelerator 4000. Escriba el comando siguiente para determinar si se ha vinculado una biblioteca de PKCS #11:

   $ ikeadm get stats … PKCS#11 library linked in from /usr/lib/libpkcs11.so $

   ---

   Nota –

   La placa Sun Crypto Accelerator 4000 admite claves de hasta 2048 bits para RSA. Para DSA, esta placa admite claves de hasta 1024 bits.

   ---

3. Busque el ID de símbolo para la placa de Sun Crypto Accelerator 4000 conectada.

   $ ikecert tokens Available tokens with library "/usr/lib/libpkcs11.so": "Sun Metaslot "

   La biblioteca devuelve un ID de símbolo, también denominado nombre de keystore, de 32 caracteres. En este ejemplo, puede utilizar el símbolo Sun Metaslot con los comandos ikecert para almacenar y acelerar claves IKE.

   Para obtener instrucciones sobre cómo utilizar el símbolo, consulte Cómo generar y almacenar certificados de clave pública en el hardware.

   Los espacios finales se rellenan automáticamente con el comando ikecert.

Ejemplo 23–12 Búsqueda y uso de símbolos de metarranura

Los símbolos se pueden almacenar en el disco, en una placa conectada o en el almacén de claves softtoken que proporciona la estructura de cifrado de Solaris. El ID de símbolo del almacén de claves softtoken podría ser similar al siguiente.

$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

Para crear una contraseña para el almacén de claves softtoken, consulte la página del comando man pktool(1).

Un comando como el siguiente agregaría un certificado al almacén de claves softtoken. Sun.Metaslot.cert es un archivo que contiene un certificado de una autoridad de certificación.

# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

Cambio de los parámetros de transmisión de IKE (mapa de tareas)

En la tabla siguiente se incluyen los procedimientos para configurar los parámetros de transmisión para IKE.

Cambio de los parámetros de transmisión de IKE

Cuando IKE negocia claves, la velocidad de transmisión puede afectar al éxito de la negociación. Normalmente, no necesita cambiar los valores predeterminados de los parámetros de transmisión de IKE. Sin embargo, al optimizar la negociación de claves con líneas muy codificadas o al reproducir un problema, puede cambiar los valores de transmisión.

Un tiempo más prolongado permite a IKE negociar claves en líneas de transmisión poco fiables. Puede alargar determinados parámetros para que los intentos iniciales tengan éxito. Si el intento inicial no tiene éxito, puede espaciar los siguientes intentos para que haya más tiempo.

Un tiempo más breve permite aprovechar las líneas de transmisión fiables. Puede reintentar una negociación fallida con mayor rapidez para acelerar la negociación. Al diagnosticar un problema, es posible que también desee acelerar la negociación para un fallo rápido. Un tiempo más breve también permite utilizar las SA de la fase 1.

Cómo cambiar la duración de la negociación de claves IKE de fase 1

1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

   La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

   ---

   Nota –

   El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

   ---

2. Cambie los valores predeterminados de los parámetros de transmisión globales de cada sistema.

   En cada sistema, modifique los parámetros de duración de la fase 1 del archivo /etc/inet/ike/config.

   ### ike/config file on system ## Global parameters # ## Phase 1 transform defaults # #expire_timer 300 #retry_limit 5 #retry_timer_init 0.5 (integer or float) #retry_timer_max 30 (integer or float)

   expire_timer

   Número de segundos que persistirá una negociación de IKE de fase 1 sin completar antes de eliminar el intento de negociación. De modo predeterminado, el intento persiste durante 30 segundos.

   retry_limit

   El número de retransmisiones antes de que se cancele cualquier negociación de IKE. De modo predeterminado, hay cinco intentos de IKE.

   retry_timer_init

   Intervalo inicial entre retransmisiones. Este intervalo se dobla hasta alcanzar el valor de retry_timer_max. El intervalo inicial es de 0,5 segundos.

   retry_timer_max

   El intervalo máximo en segundos entre retransmisiones. El intervalo de retransmisión deja de aumentar una vez alcanzado este límite. De modo predeterminado, el limite es de 30 segundos.

3. Lea la configuración que ha cambiado en el núcleo.

   • A partir de la versión Solaris 10 4/09 actualice el ike.

     # svcadm refresh svc:/network/ipsec/ike

   • Si está ejecutando una versión anterior a Solaris 10 4/09 reinicie el sistema.

     # init 6

     También puede detener e iniciar el daemon in.iked.

Ejemplo 23–13 Cómo alargar el tiempo de negociación de IKE de fase 1

En el ejemplo siguiente, un sistema se conecta a sus equivalentes IKE mediante una línea de transmisión de alta densidad de tráfico. Los parámetros originales se encuentran en los comentarios del archivo. Los nuevos parámetros alargan el tiempo de negociación.

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180

Ejemplo 23–14 Cómo acortar el tiempo de negociación de IKE de fase 1

En el ejemplo siguiente, un sistema se conecta a sus equivalentes IKE mediante una línea de alta velocidad con poca densidad de tráfico. Los parámetros originales se encuentran en los comentarios del archivo. Los nuevos parámetros acortan el tiempo de negociación.

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20