¿Cómo puedo restringir las tarjetas inteligentes de Windows para la autenticación AD para que no se implique "anyExtendedKeyUsage"?

Question

¿Cómo puedo restringir las tarjetas inteligentes de Windows para la autenticación AD para que no se implique "anyExtendedKeyUsage"?

#1 de Thomas Pornin (2 votos)

2

Este documento describe cómo hay 3 formas de restringir un certificado de SmartCard

El campo Uso mejorado de clave define uno o más propósitos para los cuales   La clave pública puede ser utilizada. RFC 5280 dice "en general, [sic] el EKU   la extensión aparecerá solo en los certificados de la entidad final ". Certificación   Los certificados de las autoridades pueden contener entradas EKU. Permitir tarjeta inteligente   iniciar sesión dentro de un dominio de Active Directory en la cadena de tarjetas inteligentes   trust debe admitir el inicio de sesión con tarjeta inteligente (OID 1.3.6.1.4.1.311.20.2.2)   y la aplicación de autenticación de cliente (OID 1.3.6.1.5.5.7.3.2)   las políticas. El inicio de sesión de tarjeta inteligente de Active Directory es compatible con el   siguientes configuraciones de EKU:


Todos los certificados en la cadena de confianza no afirman el Uso Mejorado de la Clave (excepto el certificado de la entidad final) el anyExtendedKeyUsage   EKU está implícito.

Todos los certificados en la cadena de confianza no afirman el uso de clave mejorada, excepto el certificado de punto de confianza raíz. Punto de confianza raíz   El campo EKU afirma el inicio de sesión con tarjeta inteligente (OID 1.3.6.1.4.1.311.20.2.2) y   Autenticación del cliente (OID 1.3.6.1.5.5.7.3.2).

Todos los certificados en el campo Uso mejorado de la clave de la cadena de confianza confirman el inicio de sesión con tarjeta inteligente (OID 1.3.6.1.4.1.311.20.2.2) y el cliente   Autenticación (OID 1.3.6.1.5.5.7.3.2).


La mejor práctica es que el certificado del punto de confianza raíz no incluya   una extensión de uso de clave mejorada. La política federal común CA   certificado no hace valer un EKU; por lo tanto, todas las políticas de aplicación   están implicados.

¿Esto significa que necesito una PKI de tarjeta inteligente dedicada en mi entorno solo para restringir las tarjetas inteligentes a la autenticación?

¿Hay alguna forma en que pueda tener una CA raíz definida para todos los usos + tarjeta inteligente, y también tener una sub-ca dedicada a las tarjetas inteligentes para poder engañar el proceso de validación de AD?

authentication public-key-infrastructure certificates smartcard active-directory

pregunta random65537 02.06.2012 - 19:48

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication public-key-infrastructure certificates smartcard active-directory

¿Hay influencias negativas en la Web de Trust? Si no, ¿hay alternativas teóricas? ¿Cuáles son los requisitos para que un generador de números aleatorios sea seguro para usar en criptografía?

score 2 · Answer 1

En general, no puede imponer una restricción como "debe usarse solo para el inicio de sesión con tarjeta inteligente". Se supone que este es el rol de la extensión de certificado Extended Key Usage ; Consulte RFC 5280 , sección 4.2.1.12:

Si la extensión está presente, el certificado DEBE ser utilizado únicamente para uno de los fines indicados.

Pero esto se basa en todas las aplicaciones que validan certificados para verificar realmente el EKU y hacer cumplir su contenido (se supone que una aplicación debe verificar si el EKU está allí y contiene su propio OID, o el% especial anyEKU OID; o, al menos, la extensión EKU debe estar ausente, si la aplicación no tiene un OID específico para sí misma). En la práctica, las aplicaciones no realizan tales comprobaciones. Algunas aplicaciones realizarán dicho procesamiento, pero no puede esperar de manera confiable que todas las aplicaciones lo hagan, incluso si se limita al mundo puro de Microsoft.

Para imponer la separación de roles, realmente necesita varias PKI (EKU debería hacerlo, pero en la práctica no es así, lo cual es triste). Hasta cierto punto, podría crear "una" PKI (es decir, una raíz) y usar distintas sub-CA, y establecer la CA subordinada como raíces (por ejemplo, presionaría la sub-CA específica para emisión de tarjetas inteligentes como "raíz" en el almacén NTAuth en el servidor de Active Directory). Tales sub-CA son CA raíz ocultas, por lo que es mejor que las manejes como tales (por ejemplo, que sean de larga duración).

En general, imponer el no uso de certificados emitidos es una misión infructuosa. Para cubrirse de manera legal, basta con publicar una Declaración de la Política de Certificación , debidamente vinculada a la extensión Certificate Policies en el certificado, donde declara en palabras sencillas que los certificados están destinados a tarjetas inteligentes inicio de sesión solamente. No es necesario (y tampoco es realmente posible con una confiabilidad del 100%) que disponga que todos los demás programas existentes rechacen sus certificados. En última instancia, cualquier aplicación puede validar los certificados como mejor le parezca.