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
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
Despliegue del escenario PKI: UMU-PKIv6 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
Despliegue del escenario Version=V3 Serial Number=13D Signature Algorithm=sha1RSA 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=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)”
Despliegue del escenario 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
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
| Página siguiente |