¿Las implicaciones de tener una cuenta de servicio en AD usan RC4 en lugar de AES para Kerberos?

7

Tengan paciencia, sé que esto es descuidado, pero aquí está la historia de fondo:

Tenemos un socio que usa Jira y está usando spnego con un back-end de autenticación personalizado que espera cierta membresía de grupo en el token. Suponiendo que el token presentado cumpla con los requisitos, al usuario se le otorga acceso de SSO a Jira.

Tenemos una confianza externa no transitiva bidireccional de uno de nuestros dominios secundarios con este socio. Dado que se trata de una confianza externa antigua y crujiente y no de una confianza de bosque selectiva, AD no mantiene la información necesaria para que Kerberos funcione para otra cosa que no sean inicios de sesión interactivos entre los dominios.

Hay un SPN registrado de su lado para este servicio, pero los clientes de mi lado no pueden encontrar este SPN, porque no es posible una referencia a Kerberos. Esto es, obviamente, un problema, ya que hace que los clientes recurran a NTLM y no se SSO.

La solución alternativa propuesta es crear también una cuenta de servicio en nuestro y registrar un SPN de nuestro lado para el mismo servicio idéntico al de ellos. Las contraseñas deberán ser idénticas en cada lado. Esto anulará la necesidad de una referencia para encontrar el SPN adecuado, ya que efectivamente lo estamos reflejando de nuestro lado y "engañamos" a los clientes de nuestro hijo para que lo usen en lugar del correcto de su lado. También proponen que bajemos el algoritmo de cifrado para estas cuentas duplicadas a RC4 en lugar de AES.

Aquí es donde mi conocimiento comienza a fallar, no sé por qué es necesario el paso de reducir el algoritmo de cifrado a RC4. Tampoco sé cuáles pueden ser las implicaciones de seguridad de ello.

¿Cuáles son las implicaciones y por qué no podemos limitarnos a AES para que esto funcione?

    
pregunta MDMarra 17.01.2013 - 03:36
fuente

2 respuestas

4

La razón más importante por la que puedo pensar por qué podrían querer usar RC4 es la compatibilidad con Jira (y / o este backend de autenticación personalizado que no podemos revisar)

La compatibilidad con AES128 se introdujo junto con Server 2008 y Vista, y AES256 con 2008 R2 y Win7. Sin embargo, el KDC negociará automáticamente hacia (por ejemplo) RC4 cuando hable con un cliente de Windows 2000, por ejemplo, durante la autenticación previa. Así que no debería haber ninguna necesidad de forzarlo.

Por supuesto, también puede configurar cuentas de usuario y de computadora para admitir o no a DES, AES128, AES256, etc.

Las implicaciones son simplemente que no es un tipo de cifrado tan fuerte como el de los nuevos AES. Pero tampoco es horrible.

Sin duda, me interesaría escuchar su razonamiento sobre por qué quieren usar RC4. El truco que está proponiendo con los SPN duplicados es otra lata de gusanos, pero el tipo de cifrado utilizado entre los clientes y los KDC no debería tener nada que ver con si funcionará.

    
respondido por el Ryan Ries 17.01.2013 - 17:12
fuente
2

Usted (o ellos , los que proponen el cambio) no da una razón para cambiar a RC4, ¿verdad? RC4 es un cifrado de flujo, que es vulnerable en algunos casos particulares:

  

RC4 tiene debilidades que argumentan en contra de su uso en nuevos sistemas. Es especialmente vulnerable cuando no se descarta el comienzo del flujo de claves de salida, o cuando se utilizan claves no aleatorias o relacionadas. ( Wikipedia )

Por lo tanto, las implicaciones de usar RC4 son una vulnerabilidad a (al menos) lo anterior. No puedo ver por qué AES no resistiría, sin una razón para el cambio ...

    
respondido por el Henning Klevjer 17.01.2013 - 08:29
fuente

Lea otras preguntas en las etiquetas