Implementación de una Bridge CA Gabriel López Millán

Implementación de una Bridge. CA Gabriel López Millán Universidad de Murcia gabilm@dif. um. es JJTT Red. IRIS 2004 - Toledo

Objetivos • Realizar una estudio de los principales modelos de certificación cruzada – Jerárquica, Peer-to-Peer, Bridge. CA, … • 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 JJTT Red. IRIS 2004 - Toledo

Contenido • Introducción • Escenario real de certificación • Modelo de confianza para una Federación de PKIs • Conclusiones y Vías Futuras JJTT Red. IRIS 2004 - Toledo

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 reverse forward • Certificado cruzado: Root. CA • 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 JJTT Red. IRIS 2004 - Toledo

Principales modelos de Certificación Cruzada - Jerárquico • Única CA Raíz • Certificación unidireccional Root. CA – CA superior CA subordinada • Fácil de implantar y mantener – Caminos de certificación sencillos Sub. CA • Modelo ideal para organizaciones con grandes end entity requerimientos de control • Útil para el caso de mono-dominios, pero surgen problemas en relaciones multi-dominio – Relaciones con otras CAs Raíz JJTT Red. IRIS 2004 - Toledo

Principales modelos de Certificación Cruzada – Peer-to-Peer • Ideado para relaciones con CAs externas • Relaciones bidireccionales Root. CA – CA 1 CA 2 – CA 2 CA 1 • Se establecen mallas de certificación • Más complejo de implantar y gestionar Root. CA – 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 JJTT Red. IRIS 2004 - Toledo

Principales modelos de Certificación Cruzada - Bridge. CA • Actúa como punto neutral Root. CA de confianza BCA • Cada CA relacionada expande la nube de confianza, según las Root. CA restricciones impuestas • Es necesario establecer un SLA para cada relación • Soluciona problema de escalabilidad anterior – n CAs n relaciones JJTT Red. IRIS 2004 - Toledo Root. CA

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” JJTT Red. IRIS 2004 - Toledo

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. ” JJTT Red. IRIS 2004 - Toledo

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 RFC 3280 – – – Basic Constraints Certificate Policies Name Constraints Policy Mapping JJTT Red. IRIS 2004 - Toledo

Contenido • Introducción • Escenario real de certificación • Modelo de confianza para una Federación de PKIs • Conclusiones y Vías Futuras JJTT Red. IRIS 2004 - Toledo

Descripción del escenario real • • Uso de la red definida por el proyecto Euro 6 IX Red IPv 6 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, Qo. S, movilidad, multihoming, … – Seguridad: AAA, DNSSec, VPNs… • Requisitos de certificación comunes Federación de PKIs JJTT Red. IRIS 2004 - Toledo

Red Euro 6 IX JJTT Red. IRIS 2004 - Toledo

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 JJTT Red. IRIS 2004 - Toledo

Contenido • Introducción • Escenario real de certificación • Modelo de confianza para una Federación de PKIs • Conclusiones y Vías Futuras JJTT Red. IRIS 2004 - Toledo

Requerimientos del escenario (I) • Cada dominio puede tener su propio modelo de certificación interno: Jerárquico, Peer-to-Peer, Bridge. CA, etc. . • Solución basada en dos niveles: – Primer nivel basado en BCA • Relaciones entre FLSD JJTT Red. IRIS 2004 - Toledo

Requerimientos del escenario(II) • Segundo nivel basado en Peer-to-Peer – Relaciones entre SLSD JJTT Red. IRIS 2004 - Toledo

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) RFC 2560 – 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) RFC 3029 – SCVP (Simple Certificate Validation Protocol). Draft JJTT Red. IRIS 2004 - Toledo

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) RFC 2797 • CMP (Certificate Management Protocol) RFC 2510 JJTT Red. IRIS 2004 - Toledo

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(Euro 6 IX) 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 CRLDistribution. Point , Authority. Information. Access y Subject. Information. Access para descubrir servicios (CRL, OCSP) y repositorios (LDAP, DNSSec) JJTT Red. IRIS 2004 - Toledo

Extensiones de certificados • • M=Mandatory O=Optional R=Recommended N=Not recomended CA CC CA EE CRLDistribution. Point M M M Authority. Information. Access M M M Basic. Constraints M M N Key. Usage M M O Name. Constraints M R N Policy. Mapping R R N Certificate. Policies R R R Subject. Information. Access R R R Subject. Alternative. Name O O R Policy. Constraints O O O Issuer. Alternative. Name O O O Authority. Key. Indentifier O O O Subject. Key. Identifier O O O JJTT Red. IRIS 2004 - Toledo

Despliegue del escenario • PKI: UMU-PKIv 6 (http: //pki. dif. um. es) • Servicios: – LDAP: Open. LDAP, • CRLs/ARLs, CCs (cross. Certificate. Pair) – 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 JJTT Red. IRIS 2004 - Toledo

Despliegue del escenario Version=V 3 Serial Number=13 D Signature Algorithm=sha 1 RSA Issuer=”CN=UMU PKI CA (pki. dif. um. es), OU=UMU DIIC, O=UMU, C=ES” Valid after=01/01/04, Valid before=31/12/06 Subject=”CN=EURO 6 IX BCA (bca. euro 6 ix. org), OU=BCA, O=EURO 6 IX” Public Key=RSA(2048) “ 1920 FA 71. . ” Fingerprint=” 51 FE CE 95…. ” Extensions: Basic Constrainst=”CA: True, path. Len=optional” Key Usage=”Digital Signature, Key Ciphered, Data Ciphered, Certificate Signature, CRL Signature” Extended Key Usage=”Email Signature, Server Authentication” CRLDistribution. Point=”http: //pki. dif. um. es/servlet/Get. CRL” Subject. Key. Identifier=” 31 32 d 1 …. ” Certificate. Policies=”OID. umu_policy_low, http: //pki. dif. um. es/cps” Policy Mappings=”{OID. umu_policy_low, OID. euro 6 ix_bca_policy}” Name Constraints= “Excluded. Subtress (O=UMU, C=ES)” Authority. Information. Access=“(OID. ocsp, http: //pki. dif. um. es/servlet/OCS PResponder), (OID. ca. Repository, ldap: //ldap. dif. um. es)” JJTT Red. IRIS 2004 - Toledo

Despliegue del escenario • Estado actual: – BCA en estado de pruebas situada en UMU – CA Raíz de UMU para el proyecto Euro 6 IX 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 – LDAPv 6, DNSSec • Validación en base a CRL, ARLs y OCSP • Interfaz basada en DVCS y SCVP JJTT Red. IRIS 2004 - Toledo

Contenido • Introducción • Escenario real de certificación • Modelo de confianza para una Federación de PKIs • Conclusiones y Vías Futuras JJTT Red. IRIS 2004 - Toledo

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-PKIv 6 JJTT Red. IRIS 2004 - Toledo

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 JJTT Red. IRIS 2004 - Toledo

¿Preguntas? gabilm@dif. um. es http: //pki. dif. um. es JJTT Red. IRIS 2004 - Toledo