Implementación de una BridgeCA (página 2)

Partes: 1, 2

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