Implementaci

1
Implementación de una BridgeCA

• Gabriel López Millán
• Universidad de Murcia
• gabilm_at_dif.um.es

2
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

3
Contenido

• Introducción
• Escenario real de certificación
• Modelo de confianza para una Federación de PKIs
• Conclusiones y Vías Futuras

4
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

reverse
forward
5
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

6
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

7
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

8
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 PKCS7 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

9
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.

10
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

11
Contenido

• Introducción
• Escenario real de certificación
• Modelo de confianza para una Federación de PKIs
• Conclusiones y Vías Futuras

12
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

13
Red Euro6IX
14
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

15
Contenido

• Introducción
• Escenario real de certificación
• Modelo de confianza para una Federación de PKIs
• Conclusiones y Vías Futuras

16
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

17
Requerimientos del escenario(II)

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

18
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

19
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

20
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(FL
  SD-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 SubjectInformationAc
  cess para descubrir servicios (CRL, OCSP) y
  repositorios (LDAP, DNSSec)

21
Extensiones de certificados
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

• MMandatory
• OOptional
• RRecommended
• NNot recomended

22
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

23
Despliegue del escenario

• VersionV3
• Serial Number13D
• Signature Algorithmsha1RSA
• IssuerCNUMU PKI CA (pki.dif.um.es), OUUMU
  DIIC, OUMU, CES
• Valid after01/01/04,Valid before31/12/06
• SubjectCNEURO6IX BCA (bca.euro6ix.org),
  OUBCA, OEURO6IX
• Public KeyRSA(2048) 1920 FA71 ....
• Fingerprint51FE CE95.
• Extensions
• Basic ConstrainstCA True, pathLenoptional
• Key UsageDigital Signature, Key Ciphered, Data
  Ciphered, Certificate Signature, CRL
  Signature
• Extended Key UsageEmail Signature, Server
  Authentication
• CRLDistributionPointhttp//pki.dif.um.es/servlet
  /GetCRL
• SubjectKeyIdentifier31 32 d1 .
• CertificatePoliciesOID.umu_policy_low,http//pki
  .dif.um.es/cps
• Policy MappingsOID.umu_policy_low,OID.euro6ix_b
  ca_policy
• Name Constraints ExcludedSubtress (OUMU,CES)
• AuthorityInformationAccess(OID.ocsp,http//pki.d
  if.um.es/servlet/OCS PResponder),(OID.caRepository
  ,ldap//ldap.dif.um.es)

24
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

25
Contenido

• Introducción
• Escenario real de certificación
• Modelo de confianza para una Federación de PKIs
• Conclusiones y Vías Futuras

26
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

27
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

28

• Preguntas?
• gabilm_at_dif.um.es
• http//pki.dif.um.es