Alternativa de Infraestructura de Seguridad Basada en ... · de Seguridad Basada en IPsec y DNSsec Rolando Chaparro Fox ... Seguridad en la capa de interconexión de redes ... (generación

Facultad de Ingeniería – UNA Centro Nacional de Computación

Alternativa de Infraestructurade Seguridad Basada en

IPsec y DNSsec

Rolando Chaparro Fox

FLIP6 Lima, PerúJunio 2005

universidad nacional de asunción

[ ]


Experiencia en la UNA

→ Modelo de infraestructura seguridad escalable→ Uso combinado de IPsec y DNSsec→ Trabajo experimental: alteraciones mínimas sobre

implementaciones.→ No requiere de cambios en el diseño de estos protocolos→ Relativamente simple

→ Alternativa al tradicional esquema de certificados y CAs

→ Servicios de seguridad pueden sustentarse en la infraestructura de red y en sus organizaciones

[ ]


De qué se trata

→ DNSsec Distribución segura de claves públicas de

entidades de red (típicamente hosts)

→ IPsec Interación con DNSsec para localizar,

recuperar y comprobar la autenticidad de estas claves públicas

[ ]


Orígenes de IPsec

→ RFC1636 (1994) Autenticación y cifrado como requerimiento para

la siguiente generación del protocolo IP (IPv6)

→ IPsec Extensión al Protocolo IP Seguridad en la capa de interconexión de redes IPv6 e IPv4 1998: IPv6 (RFC2460) IPsec (RFC2401)

[ ]


IPsec Seguridad IP

→ Extensiones de seguridad para IPv6 e IPv4

→ Capa de interconexión de redes (protección para el tráfico TCP, UDP, ICMP, etc.)

→ Criptografía simétrica

→ Asociaciones de Seguridad o SAs (canales unidireccionales)

→ Tres protocolos: AH, ESP, IKE

→ Dos modos de transmisión segura: Transporte y Túnel

[ ]


IPsec Los Protocolos

→ AH (Authentication Header) Autenticación (HMACMD5, HMACSHA1, etc.)

→ ESP (Encapsulating Security Payload) Cifrado (3DES, AES, etc.)

→ IKE (Internet Key Exchange) Intercambio dinámico de claves secretas (DH) Autenticación de las partes

+ PSK (claves secretas predefinidas)+ Firmas Digitales (RSA, DSA)

[ ]


E

kuB

mensaje mensaje cifrado

D

kpB

mensaje descifradoA B

Clave Pública de B

Clave Privadade B

cm m

Caracterización del Problema

→ A: ¿ Es esta realmente la clave pública de B ?

→ A: De hecho, ¿ cómo obtengo la clave pública de cualquier usuario o entidad ?

[ ]



→ El uso de la criptografía asimétrica plantea un nuevo conjunto de problemas.

→ De forma concreta: Cómo reconocer que una clave pública pertenece a un

usuario o host en particular y no a otro que aparenta ser éste.

Cómo poner las claves públicas a disposición de todos, brindando mecanismos simples de localización y recuperación

[ ]



→ Estos dos cuestionamientos dan pie a la formulación del concepto de PKI

→ En la práctica una las PKIs son imprescindibles para el comercio electrónico y para determinadas aplicaciones de seguridad

→ El concepto de PKI se ha establecido en los últimos años y se ha usado como punto de referencia

[ ]


E

kuB


D

kpB


Clave Pública de B

Clave Privadade B

cm m



[ ]


E

kuB


D

kpB


Clave Pública de B

Clave Privadade B

cm m



Datos de Id. de BFirma Digital ....

Certificado CAF6A2...

[ ]



→ Las actuales PKIs presentan aún estimables desafíos Cuando se pretende extender sus soluciones a una gran

cantidad de usuarios (escalabilidad) Cuando se busca la interacción entre usuarios de PKIs

diferentes (interoperabilidad)

→ El reto consiste consiste en solucionar estos problemas sin incrementar la complejidad del sistema al punto de que se torne difícil de manejar para los usuarios finales

[ ]


DNS Domain Name System

→ Espacio de nombres de la infraestructura de red

HTTP SMTP SSHFTP

TCP UDP

LDAP

IP

Ap

licaci

ón

Tra

nsp

ort

eR

ed

DNS (Domain Name System) Pro

toco

los d

e In

frae

structu

ra

[ ]


DNS Domain Name System

→ Servicio de directorio simple y eficaz

→ Escalable,

→ Naturaleza distribuida,

→ Alta disponibilidad

→ Balance de carga

→ Espacio de nombres de la infraestructura de red

→ Las propias CAs han planteado usar al DNS para facilitar la localización de sus repositoriosRLS: Repository Locator Service (indirección)

[ ]


DNSsec

Las extensiones de Seguridad→ Inclusión de firmas digitales en las respuestas a

las consultas DNS

→ Los resolvers DNSsec realizan verificaciones criptográficas para comprobar la validez delas respuestas recibidas

Autenticación del origen de los datos Integridad de los datos transmitidos

→ Define su propia jerarquía de autenticación denominada authenticationchain

[ ]


Definición del Modelo

Nuevo RR APPKEY→ Clave pública asociada a un host u otra entidad

→ RFC3445 (2002): Limiting the Scope of the KEY RR

→ RFC4025 (2005): A Method for Storing IPsec Keying in DNS

www.cnc.una.py 3600 IN APPKEY 256 1 2 AQPdWbrGbV[...]xB1qTmA6bI8B

Clave PúblicaAplicación o Protocolo (ssh, email, web, IPsec, ...)

Algoritmo (RSA, DSA,...)Flags: Uso (cifrado, firma,...)

RDATA

[ ]


IPsec Componentes

→ Esquema básico de componentes de IPsec

Otros

RIPEMD160

Otros

IKE

IPv4 / IPv6

Protocolosde Aplicación

TCP / UDP

IPsec

API SocketFrontera del

Kernel

AF_INET PF_KEY

SPDSAD

ESP

PF_KEY

AHHMACSHA1

HMACMD5

Cast128

BlowfishCBC

3DESCBC

Administrador

Claves Negociadas con la otra parte

[ ]


IKE Internet Key Exchange

→ Esquema básico de interacción

IKE

IPv4 / IPv6IPsec


TCP / UDP

IP

UDP


Kernel

AF_INET PF_KEY AF_INET

IKEProtocolos

de Aplicación

TCP / UDP

IP

UDP

AF_INETPF_KEYAF_INET

UDP 500

IPsec(AH/ESP/IPcomp)

Host A Host B

SPD

SAD IPv4 / IPv6IPsec

SPD

SAD

[ ]



Interacción IPsec/IKE/DNS→ Equema básico de interrelación

entre IPsec, IKE y DNSsec


TCP / UDPUDP

AF_INETPF_KEYAF_INET

Host B

IKE

IKE

IPv4 / IPv6IPsec


TCP / UDP

IP

UDP


Kernel

AF_INET PF_KEY AF_INET

Host A

SPD

SAD

Sistema DNS

ServidorDNS Localde Host A

ServidorAutoritatvode Host B

ServidorDNS Localde Host B

ServidorAutoritatvode Host A

Obtención deAPPKEY de A

(UDP 53)

Obtención deAPPKEY de B

(UDP 53)

Negociación de las claves simétricas, autenticación delas partes, establecimiento

de asociaciones de seguridad(UDP 500)

[ ]



Consultas DNSsec desde IKE→ Interacción con DNSsec al final de la Fase 1

IKE(Host A)

ServidorDNS local

ServidoresDNS

IKE(Host B)

Parámetros IKE(algoritmos de cifrado y hash,

método de autenticación, grupos DH)

Negociación de Claves(generación de valores DH y nonces,

cómputo de shared secret)

Autenticación de las Partes(obtención de PKs, intercambioy comprobación de identidades)

Fase

1Fa

se 2

Query: HOSTB IN APPKEY

Resp: HOSTB IN APPKEY(mensaje DNS de respuesta,

incluyendo clave pública de Host B)

ResoluciónRecursiva

Establecimiento SAs de IPsec(negociación de parámetros IPsec, SPI,

intercambio de nonces para derivarclaves de sesión a partir del shared secret

de IKE, opcionalmente intercambio devalores DH para generar nuevas claves)

[ ]



Consultas DNSsec desde IKE→ Interacción con DNSsec al final de la Fase 1

IKE(Host A)

ServidorDNS local

ServidoresDNS

IKE(Host B)

Parámetros IKE(algoritmos de cifrado y hash,

método de autenticación, grupos DH)

Negociación de Claves(generación de valores DH y nonces,

cómputo de shared secret)

Autenticación de las Partes(obtención de PKs, intercambioy comprobación de identidades)

Fase

1Fa

se 2

Query: HOSTB IN APPKEY

Resp: HOSTB IN APPKEY(mensaje DNS de respuesta,

incluyendo clave pública de Host B)

ResoluciónRecursiva

Establecimiento SAs de IPsec(negociación de parámetros IPsec, SPI,

intercambio de nonces para derivarclaves de sesión a partir del shared secret

de IKE, opcionalmente intercambio devalores DH para generar nuevas claves)

[ ]


Implementación del Modelo

Interacción IPsec/IKE/DNS→ Prueba de concepto del Modelo de Infraestructura de

Seguridad basado en IPsec y DNSsec

→ Una adaptación de IPsec sobre Linux, en la que se incorporan mecanismos para:

Enviar la consulta al servidor DNS local Recibir la respuesta como una ED tipo RR APPKEY Extraer el material criptográfico que conforma la clave pública Convertirla a la representación interna apropiada Usarla en los procedimientos de autenticación para establecer

la asociación de seguridad ISAKMP SA.

[ ]



Implementación de IKE→ Ultimo

intercambio,durante laFase 1

ident_i1sendPropuesta de

Parámetros IKE

ident_i2recv Selección deParámetros IKE

ident_r1recv

ident_r1send

Host Initiator Host Responder

ident_i2sendNegociación de Claves

(DH, Nonce)

ident_i3recv Negociación de Claves(DH, Nonce)

ident_r2recv

ident_r2send

ident_i3send AutenticaciónID, Firma

ident_i4recv AutenticaciónID, Firma

ident_r3recv

ident_r3send

Fas

e 1

[ ]




intercambiodurante laFase 1

ident_i3sendAutenticación

ID, Firma

ident_i4recvAutenticación

ID, Firma

ident_r3recv

ident_r3send

oakley_validate_auth

auth_method autenticaciónpresharedkey

presharedkey

FirmaDigital

getcert_method...payload

DNS

...local

cert_type dns_getcertX.509

RegistroAPPKEY

dnssec_getappkeyObtención del APPKEYautenticado vía DNSsec

[ ]




intercambiodurante laFase 1

ident_i3sendAutenticación

ID, Firma

ident_i4recvAutenticación

ID, Firma

ident_r3recv

ident_r3send

oakley_validate_auth

auth_method autenticaciónpresharedkey

presharedkey

FirmaDigital


DNS

...local

cert_type dns_getcertX.509

RegistroAPPKEY

dnssec_getappkeyObtención del APPKEYautenticado vía DNSsec

auth_methodautenticaciónpresharedkey

presharedkey

FirmaDigital


DNS

...local

cert_type X.509

RegistroAPPKEY

dnssec_getappkey

oakley_ph1hash_commonCómputo delvalor hash

Obtención del APPKEYautenticado vía DNSsec

getappkeysbyname ResolverDNSsec

dns_getcert

getrrsetbyname

eay_check_appkeysign Error: Firma no válida

Ok: Firma válida

[ ]


Análisis del Modelo

Servicios de seguridad en la IR→ Cualquier organización que requiera servicios de

seguridad, no necesita recurrir a una CA comercial para garantizar a los usuarios la legitimidad de las claves públicas

→ Para asegurar la autenticidad de las mencionadas claves, basta con publicarlas en el sistema DNS, con la misma facilidad con la que se publican sus direcciones IP

→ En consecuencia se tiene un modelo más simple

[ ]



Servicios de seguridad en la IR→ Un modelo más simple

Configuración deCertificado

Cache

Cliente

Internet

HandShake Cert y Negociación

HTTP/SSL

Cons/Resp IP de www

Serv. DNS Autoritativo

Servidor www

Publicación denombre DNS e IP

Serv. DNSLocal

Consultas Recursivas

Consultas RecursivasSolicitud de Certificado

Envío de PK, nombre DNSy otros datos

Distribución outoftheband de Certificados Raíz

CertificadoRaíz

Certificado

Autoridad deCertificación

Subsidiaria de Registro

[ ]



Los servicios y la infraestructura→ Un modelo más simple

Subsidiaria de Registro

Configuración deCertificado HandShake Cert y Negociación

CertificadoRaíz

Distribución outoftheband de Certificados Raíz

Solicitud de Certificado

Envío de PK, nombre DNSy otros datos

Certificado

Autoridad deCertificaciónCache

Cliente

Internet

HTTP/IPsec

Cons/Resp IP de www

Serv. DNS Autoritativo

Servidor www

Publicación de APPKEY,nombre DNS e IP

Serv. DNSLocal



Cons/Resp APPKEY de www

[ ]



Aprovechamiento del cache→ Consulta de la dirección IP (mensajes 1 10 en el ejemplo)

→ Siguientes peticionesAPPKEY

8: Consulta: IP de www.cnc.una.py9: Resp: IP de www.cnc.una.py

2: Consulta: IP de www.cnc.una.py3: Resp: consultar a NS py

6: Consulta: IP de www.cnc.una.py7: Resp: consultar a NS cnc.una.py

4: Consulta: IP de www.cnc.una.py5: Resp: consultar a NS una.py

12: Consulta: APPKEY de www.cnc.una.py13: Resp: APPKEYde www.cnc.una.py

1: Consulta: IP de www.cnc.una.py10: Resp: IP de www.cnc.una.py

11: Consulta: APPKEY de www.cnc.una.py14: Resp: APPKEYde www.cnc.una.py

NS Raíz

NS py

NS una.py

NS cnc.una.pyMensajes DNS propiciados

por la Aplicación

Mensajes DNS propiciadospor IKE (APPKEY) Cache

ServidorDNS Local

Cliente

[ ]



Aprovechamiento del cache→ Cache hits de varios servidores DNS en función

a la cantidad de clientes Aquellas claves

más requeridas serán recuperadas localmente

Mejor aprovechamiento del ancho de banda y una importante ventajasobre SSL y TLS

Aci

ert

os

(%)

Cantidad de Clientes

MIT 2000-01

MIT 2000-12KAIST 2001-05

[ ]



Los nombres→ PKIs basadas en CAs

Los DNs no reflejan ninguna organización jerárquica(no existen requerimientos operacionales para ello)

C=Paraguay

Raíz

Inconsistencias

C=ParaguayO=Gobierno CentralOU=Secretaría de Economía....

O=Gobierno Central O=Gobierno Nacional O=Poder Ejecutivo

C=ParaguayO=Gobierno NacionalOU=Secretaría de Educación....

C=ParaguayO=Poder EjecutivoOU=Secretaría de Educación....

C=Paraguay

Raíz

O=Empresa XYZ

CA 1 CA 2

[ ]



Los nombres→ Esto no ocurre con el DNS

La operación del DNS y la responsabilidad de asignación de los nombres de dominio se distribuye y delega efectivamente de manera jerárquica.

El DNS es una verdadera estructura de árbol en la que se asegura la unicidad de los nombres

Existe una clara dependencia por parte de las CAs hacia el DNS, dado que éste es el espacio de nombres de la infraestructura de red en la que se pretende desplegar los servicios de seguridad (En SSL se usa el FQDN en el DN del certificado)

[ ]



Confianza y autoridad→ Confianza (trust) y Autoridad (authority)

Las CAs son TTPs+ La confianza es en sí misma una relación compleja,

no transitiva, de carácter relativo, no cuantificable y culturalmente influenciada

+ Consecuencias para la interoperabilidad de los procedimientos de autenticación

En cambio, si una entidad es autoritativa sobre un determinado espacio de nombres, la difusa y elusiva noción de confiabilidad se vuelve irrelevante

[ ]




Uno no se cuestiona :+ Si se deposita o no confianza en una determinada

empresa para entregar carnés de identificación a sus propios empleados,

+ Si un determinado país está autorizado a expedir pasaportes a sus ciudadanos

En estos ejemplos, cada entidad emisora es autoritativa sobre el espacio de nombres en el que estas credenciales son emitidas, de modo que la confianza es intrínseca

[ ]




En Internet, cada organización tiene autoridad sobre su segmento del espacio de nombres de dominio+ Autoridad respecto a las denominaciones+ Autoridad respecto a los datos asociados

a los nombres+ Autoridad para delegar en una nueva zona

subordinada+ Autoridad para firmar y publicar las claves de sus

entidades, empleando para ello el RR APPKEY

[ ]



El rol de las organizaciones→ Acaso las CAs no tiene un importante rol ?

→ Las ccTLD Authorities con orgs. de soporte Gran similitud entre ops. registro de nombres de dominio

bajo un ccTLD y las solicitudes de certificados a una CA(en la práctica es un prerequisito tener un nombre DNS)

Las ccTLD Authorities de cada país tienen un vínculo más cercano con las empresas y organizaciones nacionales (mayor autoridad para las verificaciones)

Las CAs recurren a las bases de datos de las ccTLD Authorities como práctica normal para validar parte de la información suministrada por sus clientes.

[ ]



El rol de las organizaciones→ Las ccTLD Authorities con orgs. de soporte

Las ccTLD Authorities son las entidades autoritativas para la delegación de los nombres DNS a las empresas y organizaciones con presencia en Internet en cada país.

Considérese que el DNS es el espacio de nombres de la infraestructura de red sobre la que se pretende desplegar los servicios de seguridad

[ ]



El rol de las organizaciones→ Las ccTLD Authorities con orgs. de soporte

Son organizaciones ampliamente reconocidas y que tienen el respaldo de la Comunidad Internet local de cada país.

Por lo general están conformadas por asociaciones de ISPs y usuarios, o Universidades, o comités multisectoriales, en algunos casos con la participación de agencias gubernamentales.

[ ]



El rol de las organizaciones→ En resumen

El modelo propuesto no sólo se plantea el uso de protocolos base de la arquitectura TCP/IP,

Además defiende el principio de que los servicios de seguridad deben apoyarse en aquellos que están más estrechamente vinculados a la infraestructura de red de Internet+ ccTLD Authorities,

+ ISPs+ Las mismas organizaciones usuarias

[ ]



Cambio y revocación de claves→ Ante una situación de clave comprometida:

La CA debe desplegar procedimientos adicionales de seguridad que pueden demorar, aumentando la latencia entre el reporte de revocación y la distribución efectiva de la información a todas las partes

En el modelo propuesto, en cambio, es más sencilla y natural esta tarea de verificación, así como la comprobación del origen de la nueva clave+ Estas operaciones se realizan en el ámbito interno

de la misma organización

[ ]




Los mecanismos de remoción y de publicación y distribución segura de la nueva clave a los usuarios, están implícitos en el DNS y en las extensiones DNSsec, y no dependen de la intervención de una tercera parte

[ ]




El TTL del RR APPKEY en los caches juega un papel importante.

Es razonable pensar que éste parámetro no tiene porqué ser más prolongado que el tiempo de espera que transcurre en una situación de reporte de revocación remitido a una CA

→ La frecuencia de renovación de las claves y el TTL en los caches son controlados por la propia organización, sin depender de políticas particulares de las CAs

[ ]



Bytes transmitidos→ Handshake de SSL

[ ]



Bytes transmitidos→ Mensajes de la Fase 1 (modo principal) de IKE

[ ]



Bytes transmitidos→ Mensajes DNSsec propiciados por IKE

[ ]



Bytes transmitidos→ Comparación de IKE (Fase 1) y HS de SSL

Handshake de SSL 3.857 IKE F1 (principal) + DNS 2.488 (1.232 + 1.256)

Diferencia 1.369

[ ]



Roundtrips→ Comparación de IKE (Fase1) y HS de SSL

Handshake SSL IKE Fase 1 M.Principal IKE Fase 1 M.Agresivo0

1

2

3

4

5

6

7

8

9

10

11

12

TCP (ACK)

TCP (SSL)

UDP (IKE)

UDP (DNSsec)

Can

tidad

de P

aq

uete

s

[ ]



Carga computacional→ Carga computacional de la verificación

criptográfica de autenticidad de las claves públicas (y de los caminos de autenticación)

El resolver DNSsec, no la aplicación Bueno para dispositivos móviles Las verificaciones no se realizan siempre (caching)

→ La sobrecarga computacional teórica es apenas de 0.2% dominios de tercer nivel.


[ Implementación en base al modelo propuesto ]

( Capítulo 7 )

[ ]


Conclusiones

→ Modelo alternativo de infraestructura de seguridad Uso de protocolos base de Internet, Reduce la complejidad inherente al esquema de

relaciones de confianza en terceras partes

→ Existen muchos usuarios y aplicaciones que precisan Un menor grado de complejidad Mayor versatilidad

[ ]


Conclusiones

→ Nuevo registro DNS (APPKEY) Publicar las claves asociadas a las entidades de una Org. Las aplicaciones obtienen a través de DNSSEC las claves

públicas legítimas de cada host, Para luego establecer los servicios de seguridad

→ El modelo se completa con IPsec Mecanismo de interacción con DNSsec para recuperar

los registros APPKEY Autenticar a las partes durante el establecimiento de

una comunicación IP segura

[ ]


Conclusiones

→ El modelo propuesto es relativamente sencillo cubre los requerimientos de un importante número de

aplicaciones de seguridad, No recurre para a certificados digitales de las CAs

→ Esto se debe a que las claves públicas son autenticadas por las propias organizaciones autoritativas sobre el espacio de nombres de la infraestructura de red en la que se despliegan los servicios de seguridad

[ ]


Conclusiones

→ Las claves públicas son localizadas y recuperadas con la misma facilidad con la que se obtienen las direcciones IP

→ Se confiere autenticación a estas claves y se otorga a las organizaciones responsables de los servicios de red, el control de los criterios de seguridad a ser aplicados, sin depender para ello de políticas internas de las denominadas CAs

[ ]


Conclusiones

→ Una PKI que pretenda un emplazamiento extendido en toda la red Internet debe cumplir además con otros requerimientos (servicio de directorio simple y eficaz, escalabilidad, naturaleza distribuida, alta disponibilidad y balance de carga).

→ El DNS tiene todas estas características y el modelo propuesto las aprovecha al máximo, sin agregar una sobrecarga significativa al sistema bajo las actuales condiciones

[ ]


Conclusiones

→ Ventajas respecto a aplicaciones como SSL, desde el punto de vista de la latencia en la comunicación, medida en roundtrips, y del tamaño de los mensajes intercambiados

→ El aprovechamiento de caching del DNS, es un importante factor que posibilita un mejor aprovechamiento del ancho de banda, así como un mejor desempeño computacional a nivel colectivo

[ ]


Conclusiones

→ La factibilidad técnica del Modelo de Infraestructura de Seguridad basado en IPsec y DNSsec ha quedado demostrada mediante el trabajo de desarrollo presentado

→ Se ha visto cómo, a partir de alteraciones mínimas sobre las actuales implementaciones de software de estos dos protocolos, es posible proveer servicios de seguridad como la autenticación y la confidencialidad, sin la necesidad de recurrir a mecanismos de certificación que dependan de agentes externos

[ ]


Trabajos Futuros

→ Explorar viabilidad del modelo para la transmisión segura de mensajes de voz sobre redes IP

→ Evaluar el impacto del modelo propuesto sobre dispositivos móviles y equipos de bajo poder computacional

→ Proponer y desarrollar componentes de software que permitan a los MUA, recuperar las claves APPKEY para brindar servicios de cifrado de mensajes y firmas digitales

[ ]


Trabajos Futuros

→ Proponer extensiones al API o interfaz de programación de aplicaciones de red, con la finalidad de que éstas dispongan de métodos capaces de dar a conocer a las capas superiores los estados de seguridad vinculados a cada flujo de información que se va recibiendo, y luego poder asociarlos a los datos reensamblados en las aplicaciones.

[ ]


Muchas Gracias

Rolando Chaparro FoxCentro Nacional de ComputaciónUniversidad Nacional de Asunción

Documents

Alternativa de Infraestructura de Seguridad Basada en ... · de Seguridad Basada en IPsec y DNSsec Rolando Chaparro Fox ... Seguridad en la capa de interconexión de redes ... (generación