VPN Juniper

Conceptos y ejemplosManual de referencia de ScreenOS

Volumen 5:Redes privadas virtuales

Versin 6.0.0, Rev. 02Juniper Networks, Inc.1194 North Mathilda Avenue

Sunnyvale, CA 94089

USA

408-745-2000

www.juniper.net

Nmero de pieza: 530-017771-01-SP, Revisin 02

ii Copyright Notice

Copyright 2007 Juniper Networks, Inc. All rights reserved.

Juniper Networks and the Juniper Networks logo are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks in this document are the property of Juniper Networks or their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

FCC Statement

The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Juniper Networks installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:

Reorient or relocate the receiving antenna. Increase the separation between the equipment and receiver. Consult the dealer or an experienced radio/TV technician for help. Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

Paquetes IKE ...........................................................................................13Paquetes IPSec ........................................................................................16

Captulo 2 Criptografa de claves pblicas 19Contenido

Acerca de este volumen vii

Convenciones del documento ....................................................................... viiiConvenciones de la interfaz de usuario web ........................................... viiiConvenciones de interfaz de lnea de comandos .................................... viiiConvenciones de nomenclatura y conjuntos de caracteres ....................... ixConvenciones para las ilustraciones ..........................................................x

Asistencia y documentacin tcnica................................................................ xi

Captulo 1 Seguridad del protocolo de Internet 1

Introduccin a las redes privadas virtuales.......................................................2Conceptos de IPSec..........................................................................................3

Modos .......................................................................................................4Modo de transporte.............................................................................4Modo de tnel .....................................................................................4

Protocolos .................................................................................................6Encabezado de autenticacin..............................................................6Carga de seguridad encapsulada .........................................................6

Administracin de claves...........................................................................7Clave manual ......................................................................................7AutoKey IKE........................................................................................7

Asociaciones de seguridad.........................................................................8Negociacin de tnel........................................................................................9

Fase 1........................................................................................................9Modo principal y modo dinmico .....................................................10Intercambio Diffie-Hellman...............................................................11

Fase 2......................................................................................................11Confidencialidad directa perfecta......................................................12Proteccin contra reprocesamiento de paquetes...............................12

Paquetes IKE e IPSec .....................................................................................12Contenido iii

Introduccin a la criptografa de claves pblicas ............................................20Firma de un certificado ...........................................................................20Verificacin de una firma digital ..............................................................20

Infraestructura de claves pblicas ..................................................................22Certificados y CRL..........................................................................................24

Peticin manual de un certificado ...........................................................26Carga de certificados y listas de revocacin de certificados .....................28Configuracin de ajustes de CRL..............................................................29Obtencin automtica de un certificado local ..........................................31

iv

Manual de referencia de ScreenOS: Conceptos y ejemplosRenovacin automtica de certificado .....................................................34Generacin de pares de claves.................................................................35

Protocolo de estado de certificado en lnea (OCSP) ........................................35Especificacin de un mtodo de comprobacin de revocacin de

certificados .......................................................................................36Visualizacin de los atributos de comprobacin de estado ......................37Especificacin de una URL del servidor de respuesta del protocolo de

estado de certificado en lnea............................................................37Eliminacin de atributos de comprobacin de estado..............................37

Certificados autofirmados ..............................................................................38Validacin de certificados ........................................................................39Creacin manual de certificados autofirmados ........................................40Establecimiento de un certificado autofirmado y definido por el

administrador ...................................................................................41Autogeneracin de certificados................................................................45Eliminar certificados autofirmados ..........................................................46

Captulo 3 Directrices para las redes privadas virtuales 49

Opciones criptogrficas..................................................................................50Opciones criptogrficas punto a punto ....................................................50Opciones VPN de acceso telefnico .........................................................57

Tneles basados en directivas y en rutas .......................................................64Flujo de paquetes: VPN punto a punto ...........................................................66Directrices para la configuracin de tneles ...................................................72Consideraciones sobre seguridad en redes privadas virtuales basadas en

rutas ........................................................................................................74Ruta Null..................................................................................................74Lnea de acceso telefnico o arrendada ...................................................76Conmutacin por error de la VPN hacia la lnea arrendada o la ruta

Null ...................................................................................................77Interfaz Tunnel ficticia.............................................................................79Enrutador virtual para interfaces Tunnel..................................................80Reenrutamiento a otro tnel....................................................................80

Captulo 4 Redes privadas virtuales de punto a punto 81

Configuraciones VPN punto a punto...............................................................82VPN punto a punto basada en rutas, AutoKey IKE...................................88VPN punto a punto basada en directivas, AutoKeyIKE.............................97VPN punto a punto basada en rutas, interlocutor dinmico ...................103VPN punto a punto basada en directivas, interlocutor dinmico............112VPN punto a punto basada en rutas, clave manual ................................120VPN punto a punto basada en directivas, clave manual.........................127

Puertas de enlace IKE dinmicas con FQDN ................................................132Alias ......................................................................................................133Ajuste del interlocutor AutoKey IKE con FQDN......................................134

Sitios VPN con direcciones superpuestas......................................................142VPN en modo transparente..........................................................................154

Captulo 5 Redes privadas virtuales de acceso telefnico 163Contenido

Acceso telefnico .........................................................................................164VPN de acceso telefnico basada en directivas, AutoKey IKE ................165VPN de acceso telefnico basada en rutas, interlocutor dinmico .........170

ContenidoVPN de acceso telefnico basada en directivas, interlocutor dinmico ..177Directivas bidireccionales para usuarios de VPN de acceso telefnico ...184

Identificacin IKE de grupo..........................................................................188Identificacin IKE de grupo con certificados..........................................189Tipos de identificacin IKE ASN1-DN Wildcard y Container ..................191Creacin de una identificacin IKE de grupo (certificados) ....................194Configuracin de una ID IKE de grupo con claves previamente

compartidas ....................................................................................198Identificacin IKE compartida......................................................................204

Captulo 6 Protocolo de encapsulamiento de la capa 2 211

Introduccin al L2TP ....................................................................................211Encapsulado y desencapsulado de paquetes ................................................214

Encapsulado ..........................................................................................215Desencapsulado.....................................................................................216

Ajuste de los parmetros L2TP.....................................................................217L2TP y L2TP sobre IPSec..............................................................................219

Configuracin de L2TP ..........................................................................219Configuracin de L2TP sobre IPSec .......................................................224L2TP sobre IPSec bidireccional ..............................................................232

Captulo 7 Funciones avanzadas de redes privadas virtuales 239

NAT-Traversal ..............................................................................................240Sondeos de NAT ....................................................................................241Atravesar un dispositivo NAT.................................................................243Suma de comprobacin de UDP............................................................245Paquetes de mantenimiento de conexin..............................................246Simetra iniciador/respondedor .............................................................246Habilitacin de NAT-Traversal ...............................................................248Uso de identificaciones de IKE con NAT-Traversal .................................249

Supervisin de VPN......................................................................................250Opciones de reencriptacin y optimizacin...........................................251Interfaz de origen y direccin de destino...............................................252Consideraciones sobre directivas...........................................................253Configuracin de la funcin de supervisin de VPN...............................254Objetos y capturas SNMP para la supervisin de VPN............................262

Mltiples tneles por interfaz de tnel .........................................................263Asignacin de rutas a tneles ................................................................264Direcciones de interlocutores remotos...................................................266Entradas de tabla manuales y automticas ............................................267

Entradas manuales en la tabla ........................................................267Entradas automticas en la tabla.....................................................267Ajuste de VPN en una interfaz de tnel para subredes

superpuestas ............................................................................269Asociacin de entradas automticas en la tabla de rutas y en la

tabla NHTB ...............................................................................288Uso de OSPF para entradas automticas en la tabla de rutas ..........300

Puertas de enlace VPN redundantes.............................................................301Grupos VPN ...........................................................................................302Mecanismos de supervisin...................................................................303Contenido v

Pulsos de IKE ..................................................................................304Deteccin de interlocutor muerto....................................................304Procedimiento de recuperacin IKE ................................................306

vi

Manual de referencia de ScreenOS: Conceptos y ejemplosComprobacin de indicador TCP SYN....................................................307Creacin de puertas de enlace VPN redundantes ............................308

Creacin de VPN adosadas...........................................................................314Creacin de VPN radiales .............................................................................321

Captulo 8 Redes privadas virtuales de AutoConnect 331

Vista general ................................................................................................331Cmo funciona ............................................................................................332

Mensajes NHRP .....................................................................................332Iniciacin del tnel AC-VPN ...................................................................333Configuracin de AC-VPN ......................................................................334

Traduccin de direcciones de red....................................................335Configuracin en el concentrador ...................................................335Configuracin en cada red radial.....................................................335

Ejemplo .................................................................................................336

ndice ........................................................................................................................IX-IContenido

Acerca de este volumen

El Volumen 5: Redes privadas virtuales describe los conceptos de la red privada virtual (VPN) y las funciones especficas de la VPN de ScreenOS.

Este volumen contiene los siguientes captulos:

Captulo 1, Seguridad del protocolo de Internet, que presenta los elementos de Seguridad del protocolo de Internet (IPSec) y explica cmo se relacionan con el encapsulamiento de VPN.

Captulo 2, Criptografa de claves pblicas, donde se ofrece una introduccin a la criptologa de claves pblicas y al uso de certificados y listas de revocacin de certificados (CLR) en el marco de la infraestructura de claves pblicas (PKI).

Captulo 3, Directrices para las redes privadas virtuales, que explica el encapsulamiento de VPN.

Captulo 4, Redes privadas virtuales de punto a punto, que explica cmo configurar un tnel VPN punto a punto entre dos dispositivos de seguridad de Juniper Networks.

Captulo 5, Redes privadas virtuales de acceso telefnico, donde se explica cmo configurar una VPN de acceso telefnico.

Captulo 6, Protocolo de encapsulamiento de la capa 2, que describe el protocolo de encapsulamiento de capa 2 (L2TP) y proporciona ejemplos de configuraciones para L2TP y L2TP sobre IPSec.

Captulo 7, Funciones avanzadas de redes privadas virtuales, que explica los temas relacionados con las Traduccin de direcciones de red de origen (NAT), supervisin VPN y VPN que utilizan mltiples tneles.

Captulo 8, Redes privadas virtuales de AutoConnect, que describe cmo ScreenOS utiliza los mensajes del protocolo de resolucin de siguiente salto vii

(NHRP) para habilitar los dispositivos de seguridad para configurar las VPN de AutoConnect segn sea necesario. El captulo proporciona un ejemplo de un escenario tpico en el cual se puede utilizar AC-VPN.

Manual de referencia de ScreenOS: Conceptos y ejemplos

viii Convenciones del documento

Este documento utiliza las convenciones que se describen en las secciones siguientes:

Convenciones de la interfaz de usuario web en la pgina viii

Convenciones de interfaz de lnea de comandos en la pgina viii

Convenciones de nomenclatura y conjuntos de caracteres en la pgina ix

Convenciones para las ilustraciones en la pgina x

Convenciones de la interfaz de usuario webEn la interfaz de usuario web (WebUI), el conjunto de instrucciones de cada tarea se divide en ruta de navegacin y establecimientos de configuracin. Para abrir una pgina de WebUI e introducir parmetros de configuracin, navegue hacia la pgina en cuestin haciendo clic en un elemento del men en el rbol de navegacin en el lado izquierdo de la pantalla, luego en los elementos subsiguientes. A medida que avanza, su ruta de navegacin aparece en la parte superior de la pantalla, cada pgina separada por signos de mayor y menor.

Lo siguiente muestra los parmetros y ruta de WebUI para la definicin de una direccin:

Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK:

Address Name: dir_1IP Address/Domain Name:

IP/Netmask: (seleccione), 10.2.2.5/32Zone: Untrust

Para abrir la ayuda en lnea para los ajustes de configuracin, haga clic en el signo de interrogacin (?) en la parte superior izquierda de la pantalla.

El rbol de navegacin tambin proporciona una pgina de configuracin de Help > Config Guide de configuracin para ayudarle a configurar las directivas de seguridad y la Seguridad de protocolo de Internet (IPSec). Seleccione una opcin del men desplegable y siga las instrucciones en la pgina. Haga clic en el carcter ? en la parte superior izquierda para la Ayuda en lnea en la Gua de configuracin.

Convenciones de interfaz de lnea de comandosLas siguientes convenciones se utilizan para presentar la sintaxis de los comandos de interfaz de lnea de comandos (CLI) en ejemplos y en texto.

En ejemplos:

Los elementos entre corchetes [ ] son opcionales.Convenciones del documento

Los elementos entre llaves { } son obligatorios.

Acerca de este volumen Si existen dos o ms opciones alternativas, aparecern separadas entre s por barras verticales ( | ). Por ejemplo:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

Las variables aparecen en cursiva:

set admin user nombre1 contrasea xyz

En el texto, los comandos estn en negrita y las variables en cursiva.

Convenciones de nomenclatura y conjuntos de caracteresScreenOS emplea las siguientes convenciones relativas a los nombres de objetos (como direcciones, usuarios administradores, servidores de autenticacin, puertas de enlace IKE, sistemas virtuales, tneles de VPN y zonas) definidos en las configuraciones de ScreenOS:

Si una cadena de nombre tiene uno o ms espacios, la cadena completa deber estar entre comillas dobles; por ejemplo:

set address trust local LAN 10.1.1.0/24

Cualquier espacio al comienzo o al final de una cadena entrecomillada se elimina; por ejemplo, local LAN se transformar en local LAN.

Los espacios consecutivos mltiples se tratan como uno solo.

En las cadenas de nombres se distingue entre maysculas y minsculas; por el contrario, en muchas palabras clave de CLI pueden utilizarse indistintamente. Por ejemplo, local LAN es distinto de local lan.

ScreenOS admite los siguientes conjuntos de caracteres:

Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de mltiples bytes (MBCS). Algunos ejemplos de SBCS son los conjuntos de caracteres ASCII, europeo y hebreo. Entre los conjuntos MBCS, tambin conocidos como conjuntos de caracteres de doble byte (DBCS), se encuentran el chino, el coreano y el japons.

Caracteres ASCII desde el 32 (0x20 en hexadecimal) al 255 (0xff); a excepcin de las comillas dobles ( ), que tienen un significado especial como delimitadores de cadenas de nombres que contengan espacios.

NOTA: Para introducir palabras clave, basta con introducir los primeros caracteres para identificar la palabra de forma inequvoca. Al escribir set adm u whee j12fmt54 se ingresar el comando set admin user wheezer j12fmt54. Sin embargo, todos los comandos documentados aqu se encuentran presentes en su totalidad.Convenciones del documento ix

NOTA: Una conexin de consola slo admite conjuntos SBCS. La WebUI admite tanto SBCS como MBCS, segn el conjunto de caracteres que admita el explorador.


x CConvenciones para las ilustracionesLa siguiente figura muestra el conjunto bsico de imgenes utilizado en las ilustraciones de este volumen:

Figura 1: Imgenes de las ilustraciones

Sistema autnomoo biendominio de enrutamiento virtual

Interfaces de zonas de seguridad:Blanco = Interfaz de zona protegida (ejemplo = zona Trust)Negro = Interfaz de zona externa(ejemplo = zona Untrust)

Dispositivos de seguridad Juniper Networks

Concentrador

Conmutador

Enrutador

Servidor

Tnel VPN

Dispositivo de red genrico

Rango dinmico de IP (DIP)Internet

Red de rea local (LAN) con una nica subredo bienzona de seguridad

Interfaz de tnel

Motor de directivasonvenciones del documento

Acerca de este volumenAsistencia y documentacin tcnica

Para obtener documentacin tcnica sobre cualquier producto de Juniper Networks, visite www.juniper.net/techpubs/.

Para obtener soporte tcnico, abra un expediente de soporte utilizando el vnculo Case Manager en la pgina web http://www.juniper.net/customers/support/ o llame al telfono 1-888-314-JTAC (si llama desde los EE.UU.) o al +1-408-745-9500 (si llama desde fuera de los EE.UU.).

Si encuentra algn error u omisin en este documento, pngase en contacto con Juniper Networks al [email protected] y documentacin tcnica xi


xii Asistencia y documentacin tcnica

Captulo 1

Seguridad del protocolo de Internet

En este captulo se presentan los elementos de la seguridad del protocolo de internet (IPsec) y se describe cmo se relacionan con el encapsulamiento de red privada virtual (VPN). Este captulo incluye las siguientes secciones:

Introduccin a las redes privadas virtuales en la pgina 2

Conceptos de IPSec en la pgina 3

Modos en la pgina 4

Protocolos en la pgina 6

Administracin de claves en la pgina 7

Asociaciones de seguridad en la pgina 8

Negociacin de tnel en la pgina 9

Fase 1 en la pgina 9

Fase 2 en la pgina 11

Paquetes IKE e IPSec en la pgina 12

Paquetes IKE en la pgina 13

Paquetes IPSec en la pgina 16 1


2 Introduccin a las redes privadas virtuales

Una red privada virtual (VPN) representa un medio de comunicacin segura entre equipos remotos de una red de rea extensa (WAN) pblica, como Internet.

Una conexin VPN puede enlazar dos redes de rea local (LAN) entre s, o un usuario de acceso telefnico remoto y una LAN. El trfico que circula entre estos dos puntos atraviesa determinados recursos compartidos, como enrutadores, conmutadores y otros equipos de red que conforman la WAN pblica. Para garantizar la seguridad de las comunicaciones VPN a travs de la WAN, los dos participantes crean un tnel de seguridad IP (IPSec).

Un tnel IPSec est formado por un par de asociaciones de seguridad (SA) unidireccionales (una a cada extremo del tnel) que especifican el ndice de parmetros de seguridad (SPI), la direccin IP de destino y el protocolo de seguridad (encabezado de autenticacin o carga de seguridad encapsulada) empleado.

Para obtener ms informacin sobre SPI, consulte Asociaciones de seguridad en la pgina 8. Para obtener ms informacin sobre los protocolos de seguridad IPSec, consulte Protocolos en la pgina 6.

A travs de la SA, un tnel IPSec puede proporcionar las siguientes funciones de seguridad:

Privacidad (por encriptacin)

Integridad de contenido (por autenticacin de datos)

Autenticacin de remitente y (si se usan certificados) prevencin de rechazo (por autenticacin de origen de datos)

Las funciones de seguridad empleadas dependen de las necesidades particulares. Si slo necesita autenticar el origen del paquete IP y la integridad de contenido, puede autenticar el paquete sin aplicar ningn tipo de encriptacin. Por otro lado, si slo le preocupa preservar la privacidad, puede encriptar el paquete sin aplicar ningn mecanismo de autenticacin. Tambin puede encriptar y autenticar el paquete. La mayora de los diseadores de seguridad de red se decantan por la encriptacin, la autenticacin y la proteccin contra reprocesamiento de paquetes para el trfico VPN.

ScreenOS admite la tecnologa IPSec para la creacin de tneles VPN con dos tipos de mecanismos de elaboracin de claves:

Clave manual

AutoKey IKE con un certificado o una clave previamente compartida

NOTA: El trmino tnel no denota ni transporte ni modo de tnel (consulte Modos en la pgina 4). Se refiere a la conexin IPSec.Introduccin a las redes privadas virtuales

Captulo 1: Seguridad del protocolo de InternetConceptos de IPSec

La seguridad IP (IPSec) es un conjunto de protocolos relacionados utilizados para garantizar la seguridad de las comunicaciones en la capa de paquetes IP mediante encriptacin. La IPSec se compone de dos modos y dos protocolos principales:

Modos de tnel y de transporte

Protocolo de encabezado de autenticacin (AH) para la autenticacin y protocolo de carga de seguridad encapsulada (ESP) para la encriptacin (y la autenticacin)

IPSec tambin ofrece mtodos para la negociacin manual y automtica de asociaciones de seguridad (SA) y distribucin de claves; todos los atributos necesarios para ello estn reunidos en un dominio de interpretacin (DOI). Consulte las normas RFC 2407 y RFC 2408.

Figura 2: Arquitectura IPSec

Nota: ScreenOSno admite el modo de transportetransporte con AH.

Modo de transporte Modo de tnel

Protocolo ESP

Algoritmo de encriptacin(DES, 3DES)

Protocolo AH

Algoritmo de autenticacin(MD5, SHA-1)

Dominio de interpretacin(DOI)

Administracin de claves y SA(manual y automtica)

NOTA: El dominio de interpretacin (DOI) IPSec es un documento que contiene definiciones para todos los parmetros de seguridad requeridos para la negociacin satisfactoria de un tnel VPN (fundamentalmente, todos los atributos necesarios para las negociaciones IKE y SA).Conceptos de IPSec 3


4 ModosLa seguridad IPSec funciona en uno de dos modos: transporte o tnel Cuando ambos extremos del tnel son hosts, se puede utilizar tanto el modo de transporte como el modo de tnel. Cuando al menos uno de los puntos finales de un tnel es una puerta de enlace de seguridad (como un enrutador o un cortafuegos), hay que utilizar el modo de tnel. Los dispositivos de seguridad de Juniper Networks funcionan siempre en modo de tnel cuando se trata de tneles IPSec y en modo de transporte cuando se trata de tneles L2TP sobre IPSec.

Modo de transporteEl paquete IP original no est encapsulado en otro paquete IP, como se muestra en la Figura 3. El paquete completo se puede autenticar (con AH), la carga se puede encriptar (con ESP), y el encabezado original contina en texto sin formato tal como se enva por la WAN.

Figura 3: Modos de transporte

Modo de tnelEl paquete IP original completo (carga y encabezado) est encapsulado dentro de otra carga IP y tiene adjunto un nuevo encabezado, como se muestra en la Figura 4. El paquete original completo se puede encriptar, autenticar o ambas cosas. Con AH, se autentican el AH y los nuevos encabezados. Con ESP, se autentica el encabezado ESP.

Figura 4: Modos de tnel

Modo de transporte, AH

Modo de transporte, ESP

Paquetes IP

Original AH Carga de datos

Autenticado

Carga de datosESPOriginal

EncriptadoAutenticado

Modo de tnel, AH

Modo de tnel, ESP

Paquetes IP

Encabezado original Carga de datos

Autenticado

Carga de datosEncabezado original

EncriptadoAutenticado

El paquete original est encapsulado.

Encabezado AH

Encabezado ESP

Nuevo encabezado

Nuevo encabezadoConceptos de IPSec

Captulo 1: Seguridad del protocolo de InternetEn una VPN punto a punto, las direcciones de origen y destino utilizadas en el encabezado nuevo son las direcciones IP de la interfaz de salida (en modo de ruta o NAT) o la direccin IP VLAN1 (en modo transparente); las direcciones de origen y destino de los paquetes encapsulados son las direcciones de los puntos finales definitivos de la conexin.

Figura 5: VPN punto a punto en modo de tnel

En una VPN de acceso telefnico no existe ninguna puerta de enlace de tnel en el extremo del tnel correspondiente al cliente de acceso telefnico VPN; el tnel se prolonga directamente hasta el propio cliente. En este caso, en los paquetes enviados desde el cliente de acceso telefnico, tanto el encabezado nuevo como el encabezado encapsulado original tendrn la misma direccin IP: la del equipo del cliente.

Figura 6: VPN de acceso telefnico en modo de tnel

LAN

Dispositivo APuerta de enlace de tnel

Internet

Tnel

Dispositivo BPuerta de enlace de tnel

LAN

2B

1

A

Carga de datos 1 2 A B Carga de datos


A B A B Carga de datos

NOTA: Algunos clientes VPN, como NetScreen-Remote, permiten definir una direccin IP interna virtual. En estos casos, la direccin IP interna virtual es la direccin IP de origen en el encabezado del paquete original del trfico originado por el cliente, y la direccin IP que el ISP asigna dinmicamente al cliente de acceso telefnico es la direccin IP de origen en el encabezado externo.

Cliente VPN de acceso telefnico

Internet

Tnel

Dispositivo BPuerta de enlace de tnel

LAN

2 BA = 1

Carga de datos 1 2 A B Carga de datos


A B A B Carga de datosConceptos de IPSec 5


6 ProtocolosIPSec utiliza dos protocolos para garantizar la seguridad de las comunicaciones en la capa IP:

Encabezado de autenticacin (AH): protocolo de seguridad que sirve para autenticar el origen de un paquete IP y verificar la integridad de su contenido

Carga de seguridad encapsulada (ESP): protocolo de seguridad que sirve para encriptar el paquete IP completo (y autenticar su contenido)

Encabezado de autenticacinEl protocolo de encabezado de autenticacin (AH) ofrece un medio para verificar la autenticidad/integridad del contenido y el origen de un paquete. Puede autenticar el paquete por la suma de comprobacin calculada a travs de un cdigo de autenticacin de mensajes basado en hash (HMAC) mediante una clave secreta y funciones MD5 o SHA-1 hash.

Message Digest versin 5 (MD5): Un algoritmo que produce un hash de 128 bits (tambin se denomina una firma digital o resumen del mensaje) a partir de un mensaje de longitud arbitraria y una clave de 16 bytes. El hash resultante se utiliza, como si fuese la huella dactilar de la entrada, para verificar la autenticidad y la integridad del contenido y el origen.

Secure Hash Algorithm-1 (SHA-1): Un algoritmo que produce un hash de 160 bits a partir de un mensaje de longitud arbitraria y una clave de 20 bytes. Normalmente, se considera ms seguro que MD5 debido al mayor tamao del hash que produce. Como el procesamiento computacional se realiza en ASIC, el coste de rendimiento es insignificante.

Carga de seguridad encapsuladaEl protocolo de carga de seguridad encapsulada (ESP) proporciona un medio para garantizar la privacidad (encriptacin), la autenticacin de origen y la integridad de contenidos (autenticacin). El protocolo ESP en modo de tnel encapsula el paquete IP completo (encabezado y carga) y adjunta un nuevo encabezado IP al paquete que ya se encript. Este nuevo encabezado IP contiene la direccin de destino necesaria para enrutar los datos protegidos a travs de la red.

Con ESP, es posible encriptar y autenticar, slo encriptar o slo autenticar. Para la encriptacin se puede seleccionar uno de los siguientes algoritmos de encriptacin:

Norma de encriptacin de datos (DES): Un algoritmo de bloque criptogrfico con una clave de 56 bits.

Triple DES (3DES): Una versin ms potente de DES en la que el algoritmo

NOTA: Para obtener ms informacin sobre los algoritmos MD5 y SHA-1, consulte las siguientes normas RFC: (MD5) 1321, 2403; (SHA-1) 2404. Para obtener informacin sobre HMAC, consulte la norma RFC 2104.Conceptos de IPSec

original DES se aplica en tres rondas utilizando una clave de 168 bits. DES ofrece un ahorro de rendimiento significativo, pero no se considera aceptable para numerosas transferencias de material delicado o clasificado.

Captulo 1: Seguridad del protocolo de Internet Norma de encriptacin avanzada (AES): norma de encriptacin que, cuando sea adoptada por las infraestructuras de Internet de todo el mundo, ofrecer una mayor interoperabilidad con otros dispositivos de seguridad de red. ScreenOS admite AES con claves de 128, 192 y 256 bits.

Para la autenticacin, puede utilizar algoritmos MD5 o SHA-1.

Administracin de clavesLa distribucin y la administracin de claves son fundamentales para el uso satisfactorio de las redes VPN. IPSec admite los mtodos de distribucin de claves manual y automtico.

Clave manualCon las claves manuales, los administradores de ambos extremos de un tnel configuran todos los parmetros de seguridad. sta es una tcnica viable para redes pequeas y estticas, donde la distribucin, el mantenimiento y el seguimiento de las claves no resulta difcil. Sin embargo, la distribucin segura de configuraciones de clave manual a travs de largas distancias genera problemas de seguridad. Excepto en el caso de que las claves se transmitan cara a cara, no es posible estar completamente seguro de que las claves no hayan quedado comprometidas durante la transferencia. Adems, a la hora de modificar la clave nos enfrentamos a los mismos problemas que a la hora de distribuirla inicialmente.

AutoKey IKECuando es necesario crear y administrar numerosos tneles, se requiere un mtodo en el que no haya que configurar cada elemento de forma manual. IPSec admite la generacin y negociacin automatizada de claves y asociaciones de seguridad mediante el protocolo de intercambio de claves de Internet (IKE). ScreenOS denomina estas negociaciones de tnel automatizadas AutoKey IKE y admite AutoKey IKE con claves previamente compartidas y AutoKey IKE con certificados.

AutoKey IKE con claves previamente compartidas

Si AutoKey IKE utiliza claves previamente compartidas para autenticar a sus participantes en una sesin IKE, cada parte debe configurar e intercambiar de forma segura la clave compartida por adelantado. En este sentido, el problema de distribucin segura de claves es idntico al que presentan las claves manuales. Sin embargo, al contrario de lo que ocurre con las claves manuales, una AutoKey, una vez distribuida, puede modificar sus claves automticamente a intervalos predeterminados mediante el protocolo IKE. Con frecuencia, la modificacin de claves aumenta la seguridad de forma considerable. Adems, la automatizacin de esta tarea reduce significativamente las responsabilidades de administracin de claves. Sin embargo, la modificacin de claves eleva el nivel mximo de trfico; por lo tanto, si se realiza a menudo, puede disminuir la eficacia de la transmisin de

NOTA: Aunque es posible seleccionar NULL para la autenticacin, se ha demostrado que IPSec puede ser vulnerable a ataques bajo tales circunstancias. Por lo tanto, no es recomendable seleccionar NULL para la autenticacin.Conceptos de IPSec 7

datos.


8 AutoKey IKE con certificados

Cuando se utilizan certificados para autenticar a los participantes durante una negociacin AutoKey IKE, cada parte genera un par de claves pblicas/privadas (consulte Criptografa de claves pblicas en la pgina 19) y adquiere un certificado (consulte Certificados y CRL en la pgina 24). Si la autoridad de certificacin (CA) es fiable para ambas partes, los participantes podrn recuperar la clave pblica del interlocutor y verificar la firma del interlocutor. No es necesario realizar un seguimiento de las claves y SA; IKE lo hace automticamente.

Asociaciones de seguridadUna asociacin de seguridad (SA) es un acuerdo unidireccional entre los participantes VPN por lo que respecta a los mtodos y parmetros empleados para garantizar la seguridad de un canal de comunicaciones. Una comunicacin bidireccional completa requiere al menos dos SA, una para cada direccin.

Una SA agrupa los siguientes componentes para garantizar la seguridad de las comunicaciones:

Claves y algoritmos de seguridad

Modo de protocolo (transporte o tnel)

Mtodo de administracin de claves (clave manual o AutoKey IKE)

Periodo de vigencia de SA

Para el trfico VPN saliente, la directiva invoca la SA asociada al tnel VPN. Para el trfico entrante, el dispositivo de seguridad consulta la SA mediante los siguientes tres elementos:

IP de destino

Protocolo de seguridad (AH o ESP)

Valor del ndice de parmetros de seguridad (SPI)

NOTA: Una clave previamente compartida es una clave que se utiliza tanto para la encriptacin como para la desencriptacin y que ambos participantes deben poseer antes de iniciar la comunicacin.

NOTA: Para obtener ejemplos de ambos tneles (clave manual y AutoKey IKE), consulte Redes privadas virtuales de punto a punto en la pgina 81.Conceptos de IPSec

Captulo 1: Seguridad del protocolo de InternetNegociacin de tnel

Para un tnel IPSec de clave manual, como todos los parmetros de la SA se han definido previamente, no es necesario negociar cul SA utilizar. Bsicamente, el tnel ya se ha establecido. Cuando el trfico coincide con una directiva que utilice ese tnel de clave manual o cuando una ruta utiliza el tnel, el dispositivo de seguridad simplemente encripta y autentica los datos, como se haya determinado y los enva a la puerta de enlace de destino.

Para establecer un tnel IPSec AutoKey IKE se requieren dos fases de negociacin:

En la fase 1, los participantes establecen un canal seguro en el que negociar las SA IPSec.

En la fase 2, los participantes negocian las SA IPSec para encriptar y autenticar los sucesivos intercambios de datos de usuario.

Fase 1La fase 1 de una negociacin de tnel AutoKey IKE consiste en el intercambio de propuestas sobre cmo autenticar y garantizar la seguridad del canal. El intercambio se puede realizar en uno de estos dos modos: inmico o principal. En cualquiera de los dos modos, los participantes intercambian propuestas de servicios de seguridad aceptables, como por ejemplo:

Algoritmos de encriptacin (DES y 3DES) y de autenticacin (MD5 y SHA-1). Para obtener ms informacin sobre estos algoritmos, consulte Protocolos en la pgina 6.

Un grupo Diffie-Hellman (consulte Intercambio Diffie-Hellman en la pgina 11).

Una clave previamente compartida o certificados RSA/DSA (consulte AutoKey IKE en la pgina 7).

Una negociacin de fase 1 correcta concluye cuando ambos extremos del tnel se ponen de acuerdo para aceptar al menos un conjunto de los parmetros de seguridad de fase 1 propuestos y comienzan a procesarlos. Los dispositivos de seguridad de Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 1 y permiten definir el grado de restriccin del rango aceptable de parmetros de seguridad para la negociacin de claves.

Las propuestas predefinidas de fase 1 que ofrece ScreenOS son las siguientes:

Estndar: pre-g2-aes128-sha y pre-g2-3des-sha

Compatibles: pre-g2-3des-sha, pre-g2-3des-md5, pre-g2-des-sha y pre-g2-des-md5

Bsicas: pre-g1-des-sha y pre-g1-des-md5Negociacin de tnel 9

Tambin es posible definir propuestas de fase 1 personalizadas.


10 Modo principal y modo dinmicoLa fase 1 se puede desarrollar en modo principal o en modo dinmico. Estos dos modos se describen a continuacin.

Modo principal: el iniciador y el destinatario envan tres intercambios en dos direcciones (seis mensajes en total) para lograr los siguientes servicios:

Primer intercambio (mensajes 1 y 2): proponer y aceptar los algoritmos de encriptacin y autenticacin.

Segundo intercambio (mensajes 3 y 4): Ejecutar un intercambio Diffie-Hellman; el iniciador y el destinatario ofrecen un nmero pseudoaleatorio cada uno.

Tercer intercambio (mensajes 5 y 6): enviar y verificar las identidades.

La informacin transmitida en el tercer intercambio de mensajes est protegida por el algoritmo de encriptacin establecido en los dos primeros intercambios. Es decir, las identidades de los participantes no se transmiten de modo transparente.

Modo dinmico: El iniciador y el destinatario logran los mismos objetivos, pero en slo dos intercambios con un total de tres mensajes:

Primer mensaje: el iniciador propone la SA, inicia el intercambio Diffie-Hellman y enva un nmero pseudoaleatorio y su identidad IKE.

Segundo mensaje: El destinatario acepta la SA, autentica al iniciador y enva un nmero pseudoalatorio, su identidad IKE y si se utilizan certificados, el certificado de destinatario.

Tercer mensaje: el iniciador autentica al destinatario, confirma el intercambio y, si se utilizan certificados, enva el certificado de iniciador.

Puesto que las identidades de los participantes se intercambian en modo transparente (en los dos primeros mensajes), el modo dinmico no ofrece proteccin de identidad.

NOTA: Cuando un usuario VPN de acceso telefnico negocia un tnel AutoKey IKE con una clave previamente compartida, se debe utilizar el modo dinmico. Recuerde tambin que un usuario VPN de acceso telefnico puede utilizar una direccin de correo electrnico, un nombre de dominio completo (FQDN) o una direccin IP como su ID IKE. Un interlocutor dinmico puede utilizar una direccin de correo electrnico o un FQDN, pero no una direccin IP.Negociacin de tnel

Captulo 1: Seguridad del protocolo de InternetIntercambio Diffie-HellmanUn intercambio Diffie-Hellman (DH) permite a los participantes elaborar un valor secreto compartido. El punto fuerte de esta tcnica es que permite a los participantes crear el valor secreto a travs de un medio no seguro sin tener que transmitir este valor por la lnea. Hay cinco grupos Diffie-Hellman; ScreenOS admite los grupos 1, 2 y 5. El tamao del mdulo primario utilizado en el clculo de cada grupo vara del siguiente modo:

Grupo DH 1: mdulo de 768 bits



Cuanto mayor es un mdulo, ms segura se considera la clave generada; no obstante, cuanto mayor es un mdulo, ms tarda el proceso de generacin de claves. Como el mdulo de cada grupo DH tiene un tamao distinto, los participantes tienen que ponerse de acuerdo para utilizar el mismo grupo.

Fase 2Una vez que los participantes han establecido un canal seguro y autenticado, continan con la fase 2, en la que negocian las SA para garantizar la seguridad de los datos que se van a transmitir a travs del tnel IPSec.

Al igual que ocurre en la fase 1, los participantes intercambian propuestas para determinar los parmetros de seguridad que se van a emplear en la SA. Una propuesta de fase 2 incluye tambin un protocolo de seguridad (encabezado de autenticacin, AH, o carga de seguridad encapsulada, ESP) y algoritmos de encriptacin y autenticacin seleccionados. La propuesta tambin puede especificar un grupo Diffie-Hellman si se desea una confidencialidad directa perfecta (PFS).

Independientemente del modo utilizado en la fase 1, la fase 2 funciona siempre en modo rpido e implica el intercambio de tres mensajes.

Los dispositivos de seguridad de Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 2 y permiten definir el grado de restriccin del rango aceptable de parmetros de tnel. ScreenOS tambin ofrece una funcin de proteccin contra reprocesamiento de paquetes. El uso de esta funcin no requiere negociacin porque los paquetes se envan siempre con nmeros de secuencia. Slo existe la opcin de comprobar o no los nmeros de secuencia. (Para ms

NOTA: Las ventajes de la seguridad que ofrece el grupo DH 1 se han depreciado y no se recomienda su uso.

NOTA: Si configura mltiples propuestas (hasta cuatro) para negociaciones de fase 1, utilice el mismo grupo Diffie-Hellman para todas ellas. La misma directriz se aplica a la creacin de mltiples propuestas para negociaciones de fase 2.Negociacin de tnel 11

informacin sobre la proteccin contra reprocesamiento de paquetes, consulte Proteccin contra reprocesamiento de paquetes en la pgina 12).


12 Las propuestas predefinidas de fase 2 que ofrece ScreenOS son las siguientes:

Estndar: g2-esp-3des-sha y g2-esp-aes128-sha

Compatibles: nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha y nopfs-esp-des-md5

Bsicas: nopfs-esp-des-sha y nopfs-esp-des-md5

Tambin es posible definir propuestas de fase 2 personalizadas.

En la fase 2, los interlocutores tambin intercambian ID de proxy. Una ID de proxy es una tupla de tres partes compuesta por direccin IP local/direccin IP remota/servicio. La ID de proxy para ambos interlocutores debe coincidir, es decir, el servicio especificado en la ID de proxy para ambos interlocutores debe ser idntico, y la direccin IP local indicada para un interlocutor debe ser igual que la direccin IP remota indicada para el otro interlocutor.

Confidencialidad directa perfectaLa confidencialidad directa perfecta (PFS) es un mtodo para derivar claves de fase 2 independientes y no relacionadas con las claves anteriores. De forma alternativa, la propuesta de fase 1 crea la clave (SKEYID_d) a partir de la que se derivan todas las claves de fase 2. La clave SKEYID_d puede generar claves de fase 2 con un mnimo de procesamiento de CPU. Lamentablemente, si un interlocutor no autorizado obtiene acceso a la clave SKEYID_d, todas las claves de encriptacin quedarn comprometidas.

PFS afronta este riesgo de seguridad forzando un nuevo intercambio de claves Diffie-Hellman para cada tnel de fase 2. Por lo tanto, utilizar PFS es ms seguro, aunque el procedimiento de reencriptacin de la fase 2 puede prolongarse ligeramente si la funcin PFS est habilitada.

Proteccin contra reprocesamiento de paquetesSe produce un ataque de reproduccin cuando alguien intercepta una serie de paquetes y los utiliza posteriormente para inundar el sistema, provocando un rechazo de servicio (DoS), o para obtener acceso a la red fiable. La funcin de proteccin contra reprocesamiento de paquetes permite que los dispositivos de seguridad comprueben cada paquete IPSec para verificar si se ha recibido previamente. Si llegan paquetes fuera de un rango de secuencia especificado, el dispositivo de seguridad los rechaza.

Paquetes IKE e IPSec

Un tnel VPN IPSec consta de dos elementos importantes:

Configuracin del tnel: En primer lugar, los interlocutores establecen las asociaciones de seguridad (SA), que definen los parmetros para asegurar el trfico entre ellos. Los administradores de cada extremo pueden definir las SA manualmente, o bien dinmicamente durante las negociaciones IKE de fase 1 y Paquetes IKE e IPSec

fase 2. La fase 1 se puede desarrollar en modo principal o en modo dinmico. La fase 2 ocurre siempre en modo rpido.

Captulo 1: Seguridad del protocolo de Internet Seguridad aplicada: IPSec protege el trfico enviado entre los dos puntos terminales del tnel usando los parmetros de seguridad definidos en las SA que los interlocutores acordaron durante la configuracin del tnel. IPSec puede aplicarse en uno de dos modos: transporte o tnel. Ambos modos admiten los dos protocolos IPSec: carga de seguridad encapsulada (ESP) y encabezado de autenticacin (AH).

Para obtener una explicacin del procesamiento de paquetes que se produce durante las etapas IKE e IPSec de un tnel VPN, consulte Paquetes IKE en la pgina 13 y Paquetes IPSec en la pgina 16. Dichas secciones muestran los encabezados de los paquetes para IKE e IPSec, respectivamente.

Paquetes IKECuando un paquete de texto sin formato que requiere encapsulamiento llega al dispositivo de seguridad y no existe ninguna SA activa de fase 2 para ese tnel, el dispositivo de seguridad inicia las negociaciones IKE (y descarta el paquete). Las direcciones de origen y de destino en el encabezado del paquete IP son las de las puertas de enlace IKE local y remota, respectivamente. La carga de datos del paquete IP icnluye un segmento UDP que encapsula una asociacin de seguridad de Internet y protocolo de gestin de claves (ISAKMP), o paquete IKE. El formato de los paquetes IKE es igual para la fase 1 y la fase 2.

NOTA: Cuando se descarta el paquete IP inicial, el host de origen lo reenva. Tpicamente, para cuando el segundo paquete alcanza el dispositivo de seguridad, las negociaciones IKE se han completado y el dispositivo de seguridad lo protege (como tambin protege todos los paquetes subsiguientes de esa sesin) con IPSec antes de reenviarlo.Paquetes IKE e IPSec 13


14 Figura 7: Paquete IKE para las fases 1 y 2

El campo de carga de datos siguiente contiene un nmero que indica uno de los siguientes tipos de carga de datos:

0002Carga de datos de la negociacin SA: incluye una definicin para la SA de fase 1 o fase 2.

0004Carga de datos de la propuesta: puede ser una propuesta de fase 1 o fase 2.

0008Carga de datos de transformacin: La carga de datos de transformacin es encapsulada en una carga de datos propuesta que se encapsula en una carga de datos SA.

Encabezado IP

EncabezadoUDP

EncabezadoISAKMP

Carga de datos

Versin Longitud del encabezado Tipo de servicio Tamao total del paquete (en bytes)

Identificacin Desplazamiento del fragmento

Suma de comprobacin del encabezado

0 D M

Protocolo (17 para UDP)Tiempo de vida (TTL)

Direccin de origen (puerta de enlace del interlocutor local)

Direccin de destino (puerta de enlace del interlocutor remoto)

Opciones (si las hay) Relleno

Carga de datos IP

Encabezado UDP

Encabezado ISAKMP (para IKE)

Encabezado IPNota: ISAKMP es el formato de paquetes utilizado por IKE.

Puerto de origen (500 para IKE)

Longitud

Puerto de destino (500 para IKE)

Suma de comprobacin

Carga de datos UDP

Cookie del iniciador

Cookie del respondedor(0000 para el primer paquete)

Carga de datos siguiente Ver may Ver men Tipo del intercambio Indicadores

ID del mensaje

Longitud del mensaje

Carga de datos ISAKMPPaquetes IKE e IPSec

0010Carga de datos de intercambio de datos (KE): contiene la informacin necesaria para realizar un intercambio de claves, como un valor pblico Diffie-Hellman.

Captulo 1: Seguridad del protocolo de Internet 0020Carga de datos de identificacin (IDx).

En la fase 1, IDii indica la identificacin del iniciador, mientras IDir indica la del respondedor.

En la fase 2, IDui indica el iniciador del usuario, mientras IDur indica el respondedor.

Las identificaciones son tipos de ID IKE, como FQDN, U-FQDN, direccin IP y ASN.1_DN.

0040Carga de datos de certificados (CERT).

0080Carga de datos de peticin de certificado (CERT_REQ).

0100Carga de datos de Hash (HASH): contiene el resultado resumido de una determinada funcin de transformacin hash.

0200Carga de datos de firma (SIG): contiene una firma digital.

0400Carga de datos Nonce (Nx): contiene informacin pseudoaleatoria necesaria para el intercambio.

0800Carga de datos de notificacin.

1000Carga de datos de eliminacin ISAKMP.

2000Carga de datos de ID del vendedor (VID): puede incluirse en cualquier parte de las negociaciones de la fase 1. ScreenOS la utiliza para marcar la compatibilidad con NAT-T.

Cada carga de datos ISAKMP comienza con el mismo encabezado genrico, como se muestra en la Figura 8.

Figura 8: Encabezado genrico de la carga de datos ISAKMP

Puede haber mltiples cargas de datos ISAKMP encadenadas, indicndose cada tipo de carga de datos subsiguiente en el valor del campo del siguiente encabezado. Un valor de 0000 indica la ltima carga de datos ISAKMP. Consulte la Figura 9 en la pgina 16 para obtener un ejemplo.

Siguiente encabezado Reservado Longitud de la carga de datos (en bytes)

Carga de datosPaquetes IKE e IPSec 15


16 Figura 9: Encabezado ISAKMP con cargas de datos genricas ISAKMP

Paquetes IPSecUna vez completadas las negociaciones IKE y despus de que las dos puertas de enlace IKE hayan establecido las asociaciones de seguridad de fase 1 y fase 2 (SA), el dispositivo NetScreen aplica la proteccin IPSec a los paquetes IP de texto sin formato subsiguientes que los hosts situados detrs de una puerta de enlace IKE envan a los hosts que se encuentran detrs de la otra puerta de enlace (asumiendo que las directivas permitan el trfico). Si la SA de fase 2 especifica el protocolo de seguridad encapsulada (ESP) en modo de tnel, el paquete se parecer al que aparece debajo. El dispositivo de seguridad agrega dos encabezados adicionales al paquete original enviado por el host.

Figura 10: Paquete IPSec datos de seguridad encapsulada (ESP) en el modo de tnel

Como muestra la Figura 10, el paquete que el host iniciador construye incluye la carga de datos, el encabezado TCP y el encabezado IP interno (IP1).

SPI del iniciador

SPI del respondedor (0000 para el primer paquete)

Carga de datos siguiente(0002 para SA) Maj Ver Min Ver Tipo del intercambio Indicadores

ID del mensaje

Longitud total del mensaje

Encabezado siguiente(0004 para propuesta) Reservado Longitud de la carga de datos SA

Longitud de la carga de datos de la propuesta

Carga de datos SA

ReservadoEncabezado siguiente(0008 para transformacin)

Encabezado siguiente(0000 para fin)

Carga de datos propuesta

Reservado Longitud de la carga de datos de transformacin

Carga de datos de transformacin

Encabezadode ISAKMP

Carga de datosSA

Carga de datos

propuesta

Carga de datosde

transformacin

NOTA: Para obtener ms informacin sobre ESP, consulte Carga de seguridad encapsulada en la pgina 6. Para obtener informacin sobre el modo de tnel, consulte Modo de tnel en la pgina 4.

Paquete IPSecenviado por la puerta

de enlace IKEPaquete original

enviado por el host iniciador

EncabezadoIP2

EncabezadoESP

EncabezadoIP1

EncabezadoTCP Carga de datos

La puerta de enlace local agregaestos encabezados al paquete.Paquetes IKE e IPSec

Captulo 1: Seguridad del protocolo de InternetEl encabezado IP externo (IP2) que agrega el dispositivo de seguridad contiene la direccin IP de la puerta de enlace remota como direccin IP de destino y la direccin IP del dispositivo de seguridad local como direccin IP de origen. El dispositivo de seguridad tambin agrega un encabezado ESP entre los encabezados IP externo e interno. El encabezado ESP contiene informacin que permite al interlocutor remoto procesar correctamente el paquete al recibirlo. Se ilustra en la Figura 11 en la pgina 17.

Figura 11: Encabezado IP externo (IP2) y encabezado ESP

El campo de encabezado siguiente indica el tipo de datos contenidos en el campo de carga de datos. En el modo de tnel, este valor es 4, indicando IP-en-IP. Si se aplica ESP en el modo de transporte, este valor indica un protocolo de capa de transporte, como 6 para TCP o 17 para UDP.

Encabezado IP externo (IP2)

Versin Longitud deencabezado Tipo de servicio Tamao total del paquete (en bytes)


Suma de comprobacin del encabezadoProtocolo (50 para ESP)Tiempo de vida (TTL)

Direccin de origen (puerta de enlace del interlocutor local)

Direccin de destino (puerta de enlace del interlocutor remoto)


Carga de datos

Encabezado ESP

ndice de parmetros de seguridad (Security Parameters Index o SPI) del interlocutor remoto *

Nmero correlativo*

Vector de inicializacin* (IV) Primeros 8 octetos del campo de datos

Carga de datos** (variable)

Relleno** (0-255 bytes) Longitud de relleno** Encabezado siguiente (4 para IP)**Datos de autenticacin (variables)

Encriptado

Autenticado

* = secciones autenticadas del paquete** = secciones encriptadas del paquete

0 D MPaquetes IKE e IPSec 17


18 Figura 12: Encabezado IP interno (IP1) y encabezado TCP

Padding

Encabezado IP interno (IP1)

Versin Longitud deencabezadoTipo de servicio Tamao total del paquete (en bytes)


Suma de comprobacin del encabezadoProtocolo (6 para TCP)Tiempo de vida (TTL)

Direccin de origen (host iniciador)

Direccin de destino (host receptor)


Carga de datos

Encabezado TCP

Puerto de origen Puerto de destino

Nmero de secuencia

Nmero de reconocimiento

Longitud deencabezado Reservado Tamao de la ventana

Indicador UrgenteSuma de comprobacin


Datos

URG

ACK

PSH

RST

SYN

FIN

0 D MPaquetes IKE e IPSec

Captulo 2

Criptografa de claves pblicas

En este captulo se ofrece una introduccin a la criptografa de claves pblicas y al uso de certificados y listas de revocacin de certificados (CRL, o Certificate Revocation Lists) en el marco de las infraestructuras de claves pblicas (PKI, o Public Key Infraestructure). Este captulo incluye los siguientes temas:

Introduccin a la criptografa de claves pblicas en la pgina 20

Firma de un certificado en la pgina 20

Verificacin de una firma digital en la pgina 20

Infraestructura de claves pblicas en la pgina 22

Certificados y CRL en la pgina 24

Carga de certificados y listas de revocacin de certificados en la pgina 28

Configuracin de ajustes de CRL en la pgina 29

Obtencin automtica de un certificado local en la pgina 31

Renovacin automtica de certificado en la pgina 34

Protocolo de estado de certificado en lnea (OCSP) en la pgina 35

Generacin de pares de claves en la pgina 35

Especificacin de un mtodo de comprobacin de revocacin de certificados en la pgina 36

Especificacin de una URL del servidor de respuesta del protocolo de 19

estado de certificado en lnea en la pgina 37

Certificados autofirmados en la pgina 38

Eliminacin de atributos de comprobacin de estado en la pgina 37

Creacin manual de certificados autofirmados en la pgina 40


20 Establecimiento de un certificado autofirmado y definido por el administrador en la pgina 41

Eliminar certificados autofirmados en la pgina 46

Introduccin a la criptografa de claves pblicas

En la criptografa de claves pblicas se utiliza el par formado por una clave pblica y otra privada para encriptar y desencriptar datos. Los datos encriptados con una clave pblica, que su propietario pone a disposicin de otros usuarios, slo pueden ser desencriptados con la clave privada correspondiente, que el propietario mantendr protegida y en secreto. Por ejemplo, si Alicia quiere enviar a Juan un mensaje encriptado, utilizar la clave pblica de l para encriptarlo y, a continuacin, se lo enviar. Cuando reciba el mensaje, Juan podr desencriptarlo con su clave privada.

El mtodo inverso tambin resulta de gran utilidad; esto es, encriptar los datos con una clave privada y que se puedan desencriptar con la clave pblica correspondiente. Este mtodo se conoce como firma digital. Si, por ejemplo, Alicia desea que se sepa que ella es la autora de un mensaje, lo encripta con su clave privada y lo enva de forma pblica a Juan. A continuacin, Juan slo puede desencriptar los datos utilizando la clave pblica de Alicia, lo que significa que lo ha enviado ella.

Los conjuntos de claves privada y pblica tambin desempean un importante papel en el uso de certificados digitales. El procedimiento para firmar un certificado (por parte de una autoridad de certificacin) y, despus, verificar la firma (por parte del receptor) se desarrolla tal y como se indica en las siguientes subsecciones:

Firma de un certificado1. La autoridad de certificacin (CA) que emite el certificado lo somete a una

operacin matemtica en la que se utiliza un algoritmo hash (MD5 o SHA-1) para generar una codificacin.

2. A continuacin, la CA firma el certificado encriptando la codificacin con su clave privada. El resultado es una firma digital.

3. La CA enva el certificado firmado digitalmente a la persona que lo solicit.

Verificacin de una firma digital1. Cuando el destinatario recibe el certificado, tambin genera otra codificacin

aplicando el mismo algoritmo hash (MD5 o SHA-1) en el archivo de certificado.

2. El destinatario utiliza la clave pblica de la CA para desencriptar la firma digital.

3. El destinatario compara la codificacin desencriptada con la que se acaba de generar. Si las dos coinciden, el destinatario puede confirmar la integridad de la firma de la CA y, por extensin, la integridad del certificado que lo acompaa.Introduccin a la criptografa de claves pblicas

Captulo 2: Criptografa de claves pblicasFigura 13: Verificacin de firma digital

El procedimiento de firma digital de los mensajes enviados por dos participantes en una sesin IKE funciona de forma muy parecida, con las siguientes diferencias:

En lugar de generar una codificacin a partir del certificado de la CA, el emisor lo genera a partir de los datos del paquete IP.

En lugar de utilizar el par de claves pblica/privada de la CA, los participantes utilizan el par de claves pblica/privada del emisor.

1. La CA genera la codificacin A a partir del certificado utilizando el algoritmo hash MD5 o SHA-1.

2. Con su clave privada, la CA encripta la codificacin A. El resultado es la codificacin B, la firma digital.

3. La CA enva el certificado firmado digitalmente a la persona que lo solicit.

Emisor (CA)

Codif. A

Algoritmo hash(MD5 o SHA-1)

Cert.

Codif. B

Clave privada de la CA

Receptor

Codif. A

Algoritmo hash(MD5 o SHA-1)

Comparacin

Clave privada de la CA

Cert.

Codif. B

1. Genera la codificacin A a partir del certificado utilizando MD5 o SHA-1.

2. Utilizando la clave pblica de la CA, desencripta la codificacin B.

3. Compara la codificacin A con la B. Si coinciden, el receptor sabr que el certificado no est manipulado.Introduccin a la criptografa de claves pblicas 21


22 Infraestructura de claves pblicas

La infraestructura de claves pblicas (PKI) hace referencia a la estructura jerrquica de confianza necesaria para la correcta implementacin de la criptografa de claves pblicas. Para verificar la fiabilidad de un certificado, es necesario poder identificar una ruta de CA fiables, desde la CA que emite el certificado localmente hasta la autoridad raz de un dominio de CA.

Figura 14: Jerarqua de PKI en Trust Dominio de CA

La CA de nivel raz valida las CA subordinadas.

Las CA subordinadas validan certificados locales y a otras CA.

Los certificados locales contienen la clave pblica del usuario.Infraestructura de claves pblicas

Captulo 2: Criptografa de claves pblicasSi los certificados se utilizan exclusivamente dentro de una organizacin, dicha organizacin puede tener su propio dominio de CA dentro del cual una CA de la empresa emite y valida certificados entre sus empleados. Si despus esa organizacin desea que sus empleados puedan intercambiar sus certificados con otro dominio de CA (por ejemplo, con empleados de otra organizacin que tiene su propio dominio de CA), las dos CA pueden desarrollar una certificacin cruzada; es decir, pueden llegar a un acuerdo para confiar mutuamente en la autoridad de cada una de ellas. En este caso, la estructura de la PKI no se extiende en vertical, sino en horizontal.

Figura 15: Certificacin cruzada

Por motivos prcticos y de comodidad, la PKI debe administrarse e implementarse de forma transparente. Para conseguirlo, ScreenOS hace lo siguiente:

1. Genera un par de claves pblica/privada cuando se crea una peticin de certificado.

2. Proporciona esa clave pblica como parte de la peticin de certificado en un archivo de texto que se transmite a una autoridad de certificacin (CA) para la inscripcin del certificado (archivo PKCS 10).

3. Permite cargar el certificado local, el certificado de CA y la lista de revocacin de certificados (SubinterfaceCRL) en la unidad.

Tambin puede especificar un intervalo de tiempo para actualizar la CRL automticamente. Para obtener ms informacin sobre las CRL, consulte

Los usuarios del dominio A pueden utilizar sus certificados y pares de claves con los usuarios del dominio B porque ambas CA disponen de certificacin cruzada entre s.

Dominio CA: B

Certificacin cruzada

Dominio CA: A

NOTA: La autoridad de certificacin normalmente proporciona una CRL. Aunque puede cargar una CRL en el dispositivo de seguridad, no podr verla una vez cargada.Infraestructura de claves pblicas 23

Certificados y CRL en la pgina 24.

4. Permite enviar certificados cuando se establece un tnel IPSec.


24 5. Admite la validacin ascendente de rutas de certificados a travs de ocho niveles de autoridades CA en la jerarqua PKI.

6. Es compatible con la norma de criptografa PKCS 7, lo que significa que el dispositivo de seguridad puede aceptar certificados X.509 y CRL empaquetadas segn la norma PKCS 7. La compatibilidad con PKCS 7 permite enviar mltiples certificados X.509 dentro de una nica peticin PKI. Ahora es posible configurar PKI para validar a la vez todos los certificados enviados por la CA emisora.

7. Admite recuperacin de CRL en lnea a travs de LDAP o HTTP.

Certificados y CRL

Un certificado digital es un mtodo electrnico para verificar la identidad de un usuario utilizando la palabra de una tercera parte en la que se confa, conocida como autoridad de certificacin (CA). El servidor de CA que se utilice puede ser propiedad de una CA, que tambin se encargue de su manejo, o de su propia organizacin, en cuyo caso usted ser su propia CA. Si utiliza una CA independiente, debe ponerse en contacto con ella para obtener las direcciones de los servidores de CA y CRL (y conseguir certificados y listas de revocacin de certificados) o la informacin que dichos servidores necesitan cuando envan peticiones de certificados personales. Si es su propia CA, podr hacerlo usted mismo.

Para utilizar un certificado digital y as autenticar su identidad al establecer una conexin VPN segura, siga estos pasos:

Genere una clave en el dispositivo de seguridad, envela a una CA para obtener un certificado personal (que tambin se conoce como un certificado local) y cargue el certificado en el dispositivo de seguridad.

Consiga un certificado de la CA que emiti el certificado personal (bsicamente para verificar la identidad de la CA que lo verifica a usted) y cargue el certificado de la CA en el dispositivo de seguridad. Esta tarea puede realizarla

NOTA: ScreenOS admite un tamao de archivo PKCS n. 7 de hasta 7 kB.

NOTA: ScreenOS admite las siguientes CA: Baltimore, Entrust, Microsoft, Netscape, RSA Keon y Verisign.

ScreenOS dispone de un certificado de CA para las descargas de autenticacin desde el servidor de archivos de firmas de virus y el servidor de la base de datos de objetos de ataque Deep Inspection (DI). Para obtener ms informacin sobre el servidor de archivos de firmas de virus, consulte Anlisis antivirus en la pgina 4-62. Para obtener ms informacin sobre el servidor de la base de datos de objetos de ataque DI, consulte Servidor de la base de datos de objetos de ataque en la pgina 4-124.Certificados y CRL

manual o automticamente, utilizando el protocolo de inscripcin de certificado sencillo (SCEP, Simple Certificate Enrollment Protocol).

Captulo 2: Criptografa de claves pblicas Si el certificado no contiene la extensin de punto de distribucin de certificados (CDP) y no recibe automticamente la CRL a travs de LDAP o HTTP, puede obtenerla manualmente y cargarla en el dispositivo de seguridad.

Durante el proceso de negociacin, puede haber muchos casos en los que sea necesario revocar un certificado. Es posible que quiera revocar un certificado si sospecha que es peligroso o si su propietario ha dejado la empresa. Las revocaciones y validaciones de certificados se pueden administrar localmente (aunque esta solucin es limitada) o con referencia a la CRL de una CA, a la que se puede acceder en lnea de forma automtica en intervalos diarios, semanales o mensuales o segn el intervalo predefinido por la CA.

Para conseguir un certificado firmado digitalmente siguiendo el mtodo manual, debe seguir estos pasos:

1. Generar un par de claves pblica/privada

2. Llenar la peticin de certificado

3. Enviar la peticin a la CA que desee

4. Una vez recibido el certificado firmado, cargarlo en el dispositivo de seguridad junto con el certificado de CA

Ahora dispondr de los siguientes elementos con los siguientes objetivos:

Un certificado local para el dispositivo de seguridad para autenticar su identidad en cada conexin de tnel

Un certificado de CA (clave pblica de la CA), para verificar el certificado del otro interlocutor

Si la lista de revocacin de certificados (CRL) est incluida en el certificado de CA, una CRL para identificar certificados no vlidos

Cuando reciba estos archivos (los archivos de certificado suelen tener extensin la .cer y los archivos de CRL, la extensin .crl), crguelos en el dispositivo de seguridad siguiendo el procedimiento descrito en Peticin manual de un certificado en la pgina 26.

NOTA: La CRL puede acompaar al certificado de CA y se puede almacenar en la base de datos de ScreenOS Alternativamente, el certificado de CA puede contener la URL de la CRL (ya sea LDAP o HTTP) si sta se encuentra almacenada en la base de datos de la CA. Si es incapaz de obtener la CRL por cualquiera de los mtodos, puede introducir manualmente la URL de la CRL en el dispositivo de seguridad, tal y como se explica en Configuracin de ajustes de CRL en la pgina 29.

NOTA: Si piensa utilizar el correo electrnico para enviar un archivo PKCS 10 y obtener los certificados, debe configurar adecuadamente los ajustes de ScreenOS para Certificados y CRL 25

poder enviar mensajes de correo electrnico al administrador del sistema. Deber establecer los servidores DNS principal y secundario, y especificar los ajustes de direccin del servidor SMTP y del servidor de correo.


26 Peticin manual de un certificadoCuando se solicita un certificado, el dispositivo de seguridad genera un par de claves. La clave pblica se incorpora en la propia peticin y, posteriormente, en el certificado local firmado digitalmente que recibir de la CA.

En el siguiente ejemplo, el administrador de seguridad realiza una peticin de certificado para Michael Zhang en el departamento de desarrollo de Juniper Networks in Sunnyvale, California. Este certificado se utilizar en un dispositivo de seguridad con la direccin IP 10.10.5.44. El administrador ordena al dispositivo de seguridad que enve la peticin por correo electrnico al administrador de seguridad, que tiene la direccin [email protected]. A continuacin, el administrador de seguridad copia la peticin y la pega en el campo de texto de peticin de certificado en el punto de inscripcin de certificados de la CA. Una vez finalizado el proceso de inscripcin, la CA normalmente devuelve el certificado por correo electrnico al administrador de seguridad.

WebUI

1. Generacin del certificadoObjects > Certificates > New: Introduzca los siguientes datos y haga clic en Generate:

Name: Michael ZhangPhone: 408-730-6000Unit/Department: DevelopmentOrganization: Juniper NetworksCounty/Locality: SunnyvaleState: CACountry: USE-mail: [email protected] Address: 10.10.5.44Write to file: (seleccione)RSA: (seleccione)Create new key pair of 1024 length: (seleccione)

El dispositivo de seguridad genera un archivo PKCS n. 10 y solicita que enve el archivo por correo electrnico, lo guarde en disco o lo inscriba automticamente a travs del protocolo SCEP (Simple Certificate Enrollment

NOTA: Una cadena de identidad certificada especial, llamada dominio-componente, est disponible nicamente a travs de la CLI. Los dispositivos pueden utilizar este valor en certificados para que IPSec se conecte a puertas de enlace VPN. Por ejemplo, el dispositivo puede utilizarlo como una ID IKE de grupo, aceptando las identidades IKE tipo ASN1_DN que contienen DC=Ingenieros, DC=NuevaYork.

Antes de generar una peticin de certificado, compruebe que ha ajustado el reloj del sistema y que ha asignado un nombre de host y un nombre de dominio al dispositivo de seguridad. Si el dispositivo de seguridad se encuentra en un clster NSRP, sustituya el nombre de host por un nombre de clster. Para obtener ms informacin, consulte Creacin de un clster de NSRP en la pgina 11-29.)Certificados y CRL

Protocol).

Seleccione la opcin E-mail to, escriba [email protected] y despus haga clic en OK.

Captulo 2: Criptografa de claves pblicas2. Peticin de certificadoEl administrador de seguridad abre el archivo y copia su contenido, procurando copiar el texto completo pero no los espacios en blanco situados delante o detrs del texto (comenzando por -----BEGIN CERTIFICATE REQUEST----- y finalizando en -----END CERTIFICATE REQUEST-----).

A continuacin, el administrador de seguridad sigue las direcciones de la peticin de certificado en el sitio web de la CA, pegando el archivo PKCS no. 10 en el campo apropiado.

3. Recuperacin del certificadoCuando el administrador de seguridad recibe el certificado de la CA por correo electrnico, se lo reenva a usted. Cpielo en un archivo de texto y gurdelo en su estacin de trabajo (para despus cargarlo en el dispositivo de seguridad a travs de la interfaz WebUI) o en un servidor TFTP (para cargarlo a travs de CLI).

CLI

1. Generacin del certificadoset pki x509 dn country-name USset pki x509 dn email [email protected] pki x509 dn ip 10.10.5.44set pki x509 dn local-name Santa Claraset pki x509 dn name Michael Zhangset pki x509 dn org-name Juniper Networksset pki x509 dn org-unit-name Developmentset pki x509 phone 408-730-6000set pki x509 dn state-name CAset pki x509 default send-to [email protected] pki rsa new-key 1024

NOTA: Determinadas CA no admiten direcciones de correo electrnico en los certificados. Si no incluye una direccin de correo electrnico en la peticin de certificado local, no podr utilizarla como identificacin de IKE local al configurar el dispositivo de seguridad como interlocutor dinmico. En su lugar, podr utilizar un nombre de dominio completo (si se encuentra en el certificado local) o dejar el campo vaco. Predeterminadamente el dispositivo de seguridad enva su nombrehost.nombredominio. Si no especifica la identificacin local para un interlocutor dinmico, introduzca el nombrehost.nombredominio del interlocutor en el dispositivo que se encuentra en el otro extremo del tnel IPSec en el campo de identificacin del interlocutor.

El valor 1024 indica la longitud en bits del par de claves. Si va a utilizar el certificado para SSL (consulte Secure Sockets Layer en la pgina 3-5), asegrese de que utiliza una longitud de bits que tambin sea compatible con su explorador.

Si utiliza la direccin de correo electrnico, se supone que ya ha configurado la direccin IP para el servidor SMTP: set admin mail server-name { dir_ip | nombre_dom }. Certificados y CRL 27


28 La peticin de certificado se enva por correo electrnico a [email protected].

2. Peticin de certificadoEl administrador de seguridad abre el archivo y copia su contenido, procurando copiar el texto completo pero no los espacios en blanco situados delante o detrs del texto (comenzando por -----BEGIN CERTIFICATE REQUEST----- y finalizando en -----END CERTIFICATE REQUEST-----).

A continuacin, el administrador de seguridad sigue las direcciones de la peticin de certificado en el sitio web de la CA, pegando el archivo PKCS n. 10 en el campo apropiado.

3. Recuperacin del certificadoCuando el administrador de seguridad recibe el certificado de la CA por correo electrnico, se lo reenva a usted. Cpielo en un archivo de texto y gurdelo en su estacin de trabajo (para despus cargarlo en el dispositivo de seguridad a travs de la interfaz WebUI) o en un servidor TFTP (para cargarlo a travs de CLI).

Carga de certificados y listas de revocacin de certificadosLa CA le devuelve los siguientes tres archivos para que los cargue en el dispositivo de seguridad:

Un certificado de CA, que contiene la clave pblica de la CA

Un certificado local, que identifica su equipo local (su clave pblica)

Una CRL, que enumera los certificados revocados por la CA

Para el ejemplo con la WebUI, habr descargado los archivos a un directorio llamado C:\certs\ns en la estacin de trabajo del administrador. Para el ejemplo con CLI, habr descargado el directorio raz TFTP a un servidor TFTP con la direccin IP 198.168.1.5.

En este ejemplo se muestra cmo se deben cargar dos archivos distintos, llamados auth.cer (certificado de CA) y local.cer (su clave pblica), junto con el archivo de CRL llamado distrust.crl.

WebUI

NOTA: Si utiliza la direccin de correo electrnico, se supone que ya ha configurado la direccin IP para el servidor SMTP: set admin mail server-name { dir_ip | nombre_dom }.

NOTA: Los dispositivos de seguridad de Juniper Networks configurados con ScreenOS 2.5 o versiones posteriores (incluyendo los sistemas virtuales) permiten cargar certificados locales desde distintas CA.Certificados y CRL

1. Objects > Certificates: Seleccione Load Cert y despus haga clic en Browse.

2. Acceda al directorio C:\certs, seleccione auth.cer y despus haga clic en Open.

Captulo 2: Criptografa de claves pblicasLa ruta del directorio y el nombre de archivo (C:\certs\ns\auth.cer) aparecern en el campo File Browse.

3. Haga clic en Load.

Se cargar el archivo local.cer.

4. Objects > Certificates: Seleccione Load Cert y despus haga clic en Browse.

5. Acceda al directorio C:\certs, seleccione local.cer y despus haga clic en Open.

La ruta del directorio y el nombre de archivo (C:\certs\ns\local.cer) aparecern en el campo File Browse.


El archivo del certificado local.cer se carga.

7. Objects > Certificates: Seleccione Load CRL y despus haga clic en Browse.

8. Acceda al directorio C:\certs, seleccione distrust.cer y despus haga clic en Open.


Se cargar el archivo de CRL distrust.crl.

CLI

exec pki x509 tftp 198.168.1.5 cert-name auth.cerexec pki x509 tftp 198.168.1.5 cert-name local.cerexec pki x509 tftp 198.168.1.5 crl-name distrust.crl

Configuracin de ajustes de CRLEn la fase 1 de las negociaciones, los participantes consultan la lista CRL para comprobar si los certificados recibidos durante un intercambio IKE siguen siendo vlidos. Si una CRL no est cargada en la base de datos de ScreenOS, el dispositivo de seguridad intentar recuperarla mediante la ubicacin de LDAP o HTTP CRL definida en el propio certificado. Si no hay ninguna direccin URL definida en el certificado, el dispositivo de seguridad utiliza la URL del servidor definido para ese certificado de CA. Si el certificado de CA no est cargado en el dispositivo (por ejemplo, una CA intermedia de la cadena del certificado recibida durante el intercambio de IKE), no puede resolver la URL del servidor de CRL para esa CA. En este caso, puede especificar la URL del servidor de CRL en la seccin de Ajustes de validacin del certificado predeterminado de la UI de web (consulte la siguiente pgina). Una URL del servidor de CRL que se introduzca aqu slo se utilizar cuando el certificado de CA no est presente en el dispositivo. No hay una URL predeterminada.Certificados y CRL 29


30 En este ejemplo, primero configurar el servidor de CA Entrust para comprobar la CRL diariamente mediante una conexin al servidor LDAP ubicado en 2.2.2.121 y la localizacin del archivo de CRL. A continuacin configurar los ajustes predeterminados de validacin de certificados para su uso en el servidor LDAP ubicado en 10.1.1.200, comprobando tambin diariamente la CRL.

WebUI

Objects > Certificates (Show: CA) > Server Settings (para NetScreen): Introduzca los siguientes datos y haga clic en OK:

X509 Cert_Path Validation Level: FullCRL Settings:

URL Address: ldap:///CN=Entrust,CN=en2001,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=EN2001,DC=com?CertificateRevocationList?base?objectclass=CRLDistributionPoint

LDAP Server: 2.2.2.121Refresh Frequency: Daily

Objects > Certificates > Default Cert Validation Settings: Introduzca los siguientes datos y haga clic en OK:

X509 Certificate Path Validation Level: FullCertificate Revocation Settings:

Check Method: CRLURL Address:

ldap:///CN=NetScreen,CN=safecert,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=SAFECERT,DC=com?CertificateRevocationList?base?objectclass=CRLDistributionPoint

LDAP Server: 10.1.1.200

NOTA: La extensin del punto de distribucin de la CRL (.cdp) en un certificado X509 puede ser una URL HTTP o una URL LDAP.

Con ScreenOS 2.5 y versiones posteriores, al cargar la CRL puede desactivar la comprobacin de firmas digitales. Sin embargo, si desactiva la comprobacin del certificado de CRL pondr en peligro la seguridad de su dispositivo.

NOTA: El nmero de ndice (IDX) para el certificado de Entrust CA es 1. Para poder ver una lista de los nmeros IDX de todos los certificados de CA cargados en un dispositivo de seguridad, utilice el siguiente comando CLI: get pki x509 list ca-cert.Certificados y CRL

Captulo 2: Criptografa de claves pblicasCLI

set pki authority 1 cert-path fullset pki authority 1 cert-status crl url ldap:///CN=Entrust,CN=en2001,

CN=PublicKeyServices,CN=Services,CN=Configuration,DC=EN2000,DC=com?CertificateRevocationList?base?objectclass=CRLDistributionPoint

set pki authority 1 cert-status crl server-name 2.2.2.121set pki authority 1 cert-status crl refresh dailyset pki authority default cert-path fullset pki authority default cert-status crl url ldap:///CN=NetScreen,

CN=safecert,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=SAFECERT,DC=com?CertificateRevocationList?base?objectclass=CRLDistributionPoint

set pki authority default cert-status crl server-name 10.1.1.200set pki authority default cert-status crl refresh dailysave

Obtencin automtica de un certificado localPara utilizar un certificado digital y as autenticar su identidad al establecer una conexin VPN segura, siga estos pasos:

Consiga el certificado de una autoridad de certificacin (CA) de la cual desee obtener un certificado personal y crguelo en el dispositivo de seguridad.

Obtenga un certificado local (tambin llamado certificado personal) de la CA cuyo certificado de CA ya ha cargado y, a continuacin, cargue el certificado local en el dispositivo de seguridad. Esto lo puede hacer manual o automticamente, utilizando el protocolo SCEP (Simple Certificate Enrollment Protocol).

Como durante el mtodo

Documents

VPN Juniper