implementación de una bridgeca

JJTT RedIRIS 2004 - Toledo

Implementación de una BridgeCA

Gabriel López Millán

Universidad de [email protected]


Objetivos

• Realizar una estudio de los principales modelos de certificación cruzada– Jerárquica, Peer-to-Peer, BridgeCA, …

• Definir un modelo de confianza basado en una Federación de PKIs en un entorno real– Escenario multidominio– Tipos de relaciones entre las organizaciones

• Establecer los requerimientos de certificación– Servicios de certificación– Tipos y uso de las extensiones de certificados para certificación

cruzada

• Desplegar el escenario


Contenido

• Introducción• Escenario real de certificación• Modelo de confianza para una Federación de

PKIs • Conclusiones y Vías Futuras


Certificación cruzada

• Establecer relaciones de confianza entre CAs• Los certificados se pueden validar de forma automática

por las terceras partes confiables• La relación de confianza puede ser unidireccional o

bidireccional• Definidas por un certificado cruzado en cada sentido

• Certificado cruzado: • Certificado de CA firmado por otra CA• Porta las restricciones de la relación: extensiones

• Se definen caminos de certificación que hay que descubrir y validar

forward

reverse

RootCA RootCA


Principales modelos de Certificación Cruzada - Jerárquico• Única CA Raíz• Certificación unidireccional

– CA superior CA subordinada

• Fácil de implantar y mantener– Caminos de certificación sencillos

• Modelo ideal para

organizaciones con grandes

requerimientos de control• Útil para el caso de mono-dominios, pero surgen

problemas en relaciones multi-dominio– Relaciones con otras CAs Raíz

RootCA

SubCA SubCA

end entity end entity


Principales modelos de Certificación Cruzada – Peer-to-Peer• Ideado para relaciones con CAs externas• Relaciones bidireccionales

– CA1 CA2– CA2 CA1

• Se establecen mallas de certificación• Más complejo de implantar y gestionar

– Aumentan los caminos de certificación – Aumenta la longitud de estos caminos– Difíciles de descubrir (detección de búcles)

• Requiere un SLA (Service Level Agreement) entre las organizaciones

• Para n CAs n(n-1)/2 relaciones

RootCA RootCA

RootCARootCA


Principales modelos de Certificación Cruzada - BridgeCA• Actúa como punto neutral

de confianza• Cada CA relacionada expande la

nube de confianza, según las

restricciones impuestas • Es necesario establecer un SLA para cada

relación• Soluciona problema de escalabilidad anterior

– n CAs n relaciones

RootCA

RootCA

RootCA

RootCA

BCA


Principales modelos de Certificación Cruzada• Otros modelos (1)

– Cross Recognition: “The (foreign) CA is regarded as trustworthy if it has been licensed/accredited by a formal licensing/accreditation body or has been audited by a trusted independent party”.

– Certificate Trusted List: “… a signed PKCS#7 data structure that can contain, among other things, a list of trusted CAs . A trusted CA is identified within the CTL by a hash of the public key certificate of the subject CA. The CTL also contains policy identifiers and supports the use of extensions”


Principales modelos de Certificación Cruzada• Otros modelos (2)

– Accreditation Certificate: “…it introduces the use of an accreditation certificate that could be used to indicate that a given CA is accredited by the Australian government.”


Restricciones en Modelos de Certificación Cruzada• Vendrán definidas por las extensiones que

portan los certificados cruzados emitidos para establecer la relación

• Definidas en RFC3280– Basic Constraints– Certificate Policies– Name Constraints– Policy Constraints– Policy Mapping


Contenido




Descripción del escenario real

• Uso de la red definida por el proyecto Euro6IX• Red IPv6 pan-europea • Formada por IXs, proveedores de red y usuarios finales • Participan las principales operadoras europeas

– TID, TILAB, BT, FT,…

• Cada IX ofrece servicios a nivel de aplicación– Seguridad, QoS, movilidad, multihoming,…– Seguridad: AAA, DNSSec, VPNs…

• Requisitos de certificación comunes Federación de PKIs


Red Euro6IX


Tipos de relaciones• Relaciones Fuertes

– Establecidas entre IXs– Entre organizaciones bien conocidas con intereses comunes– Relación estable y duradera– Basadas en SLAs– Cada IX tendrá su propia CA Raíz– FLSD = First Level Security Domain

• Relaciones Normales-Débiles– Establecidas entre IXs y proveedores de red o entre proveedores de

red– Basadas en requerimientos de negocios o políticos– Pueden cambiar más frecuentemente– Cada proveedor de red puede tener su propia CA Raíz o usar los

servicios de un IX– SLSD = Second Level Security Domain


Contenido




Requerimientos del escenario (I)

• Cada dominio puede tener su propio modelo de certificación interno: Jerárquico, Peer-to-Peer, BridgeCA, etc..

• Solución basada en dos niveles:– Primer nivel basado en BCA

• Relaciones entre FLSD


Requerimientos del escenario(II)

• Segundo nivel basado en Peer-to-Peer – Relaciones entre SLSD


Requerimientos del escenario (III)

• Servicios de Validación– Determinan si un certificado es válido o no

• CRL/ARL• OCSP (On-line Certificate Status Protocol) RFC2560

– Utilizado por las terceras partes confiables• Usuarios• Sistemas finales (nodos VPNs, servidores, etc)

– Gestión de los caminos de certificación• Descubrimiento• Validación

• Protocolos de acceso a los servicios de validación– DVCS (Data Validation and Certification Server Protocols)

RFC3029– SCVP (Simple Certificate Validation Protocol). Draft


Requerimientos del escenario (IV)

• Acceso a repositorios públicos para descubrimiento del camino de certificación

• LDAP• DNSSec• DB interna

• Servicio de gestión de claves basado en protocolos estándar– Permiten gestionar el ciclo de vida de los certificados

digitales• CMC (Certificate Management Messages over CMS) RFC2797• CMP (Certificate Management Protocol) RFC2510


Gestión de caminos de certificación

• Bob en SLSD-C recibe mensaje protegido con clave privada de Alice en SLSD-A

• Bob confía en Alice si:– Existe un camino de certificación entre Alice y una entidad confiable

por Bob– El camino es válido

• El camino CA(SLSD‑C)CA(FLSD-1)BCA(Euro6IX)CA(FLSD-2)CA(SLSD-A)C(Alice) debe ser descubierto por el servicio de validación del dominio SLSB-C

• Algoritmo de construcción de caminos– Uso de extensiones CRLDistributionPoint ,

AuthorityInformationAccess y SubjectInformationAccess para descubrir servicios (CRL, OCSP) y repositorios (LDAP, DNSSec)


Extensiones de certificados

• M=Mandatory• O=Optional• R=Recommended• N=Not recomended

CA CC CA EE

CRLDistributionPoint M M M

AuthorityInformationAccess M M M

BasicConstraints M M N

KeyUsage M M O

NameConstraints M R N

PolicyMapping R R N

CertificatePolicies R R R

SubjectInformationAccess R R R

SubjectAlternativeName O O R

PolicyConstraints O O O

IssuerAlternativeName O O O

AuthorityKeyIndentifier O O O

SubjectKeyIdentifier O O O


Despliegue del escenario

• PKI: UMU-PKIv6 (http://pki.dif.um.es) • Servicios:

– LDAP: OpenLDAP, • CRLs/ARLs, CCs (crossCertificatePair)

– DNSSec: Bind 9.2.1, Almacena certificados: EE, CA y CRL• TSIG: interacción mediante claves simétricas• SIG(0): en proceso

– Autoridades OCSP y TSP. Basados en Java-Servlets– Autoridad de Servicios de Validación.

• Uso CRLs, OCSP y LDAP• Basado en DVCS y SCVP

– Gestión de claves: CMC. APIs: Java/Perl/C



Version=V3Serial Number=13DSignature Algorithm=sha1RSAIssuer=”CN=UMU PKI CA (pki.dif.um.es), OU=UMU DIIC, O=UMU, C=ES”Valid after=01/01/04,Valid before=31/12/06Subject=”CN=EURO6IX BCA (bca.euro6ix.org), OU=BCA, O=EURO6IX”Public Key=RSA(2048) “1920 FA71 ....”Fingerprint=”51FE CE95….”Extensions: Basic Constrainst=”CA: True, pathLen=optional”Key Usage=”Digital Signature, Key Ciphered, Data Ciphered, Certificate

Signature, CRL Signature”Extended Key Usage=”Email Signature, Server Authentication”CRLDistributionPoint=”http://pki.dif.um.es/servlet/GetCRL”SubjectKeyIdentifier=”31 32 d1 ….”CertificatePolicies=”OID.umu_policy_low,http://pki.dif.um.es/cps”Policy Mappings=”{OID.umu_policy_low,OID.euro6ix_bca_policy}”Name Constraints= “ExcludedSubtress (O=UMU,C=ES)”AuthorityInformationAccess=“(OID.ocsp,http://pki.dif.um.es/servlet/OCS

PResponder),(OID.caRepository,ldap://ldap.dif.um.es)”



• Estado actual:– BCA en estado de pruebas situada en UMU– CA Raíz de UMU para el proyecto Euro6IX

conectada a BCA– Varias CAs raíces piloto conectadas a la BCA– Desarrollo de la Autoridad de Servicios de Validación

• Descubrimiento de caminos– Extensiones de certificación

– LDAPv6, DNSSec

• Validación en base a CRL, ARLs y OCSP• Interfaz basada en DVCS y SCVP


Contenido




Conclusiones

• Implantación de una Federación de PKIs basada en BCA en un entorno real

• Fácilmente exportable a otros escenarios• Recursos y entidades interesadas• Es necesario definir formalmente como gestionar SLAs

– Establecimiento, Renovación, Revocación

• Reduce la sobrecarga de la gestión de seguridad dentro de la Federación

• Es necesario definir requisitos:– Servicios, Protocolos, Certificados

• Uso de UMU-PKIv6


Vías Futuras

• Despliegue de la infraestructura en cada IX y proveedor de red del proyecto

• Migración a otros escenario• Uso en entornos de roaming

• Integración con aplicaciones y servicios basados en certificación X.509


¿Preguntas?

[email protected]

http://pki.dif.um.es

implementación de una bridgeca

Documents