Autenticación compuesta Kerberos que refleja el origen del usuario

1

Estoy experimentando con Kerberos y me preguntaba si algún tipo de La autenticación compuesta que identifica tanto un usuario como el origen de la solicitud de los usuarios fue a) posible y b) implementada en cualquier lugar.

Lo que busco es una configuración donde hay un intermedio entidad (podría ser la máquina de los usuarios, podría ser el enrutador el cliente se está conectando a través de) que altera los mensajes de un cliente a un servidor de autenticación (AS) para que identifiquen tanto al usuario como el origen de la solicitud. Luego, el AS puede tomar en consideración esta alteración y devolver un TGT que puede usarse para otorgar acceso según la fuente.

Esto podría usarse, por ejemplo, si tuviera un terminal de computadora En el mostrador de una tienda y otro en el back office. Cada terminal alteraría las solicitudes al AS para reflejar la fuente, y La terminal en el mostrador de la tienda podría tener menos acceso ya que es potencialmente más vulnerable.

Soy consciente de las principales instancias pero mi entendimiento es que estos son solo considerados como principios separados y El usuario debe tener diferentes credenciales para cada instancia. Estoy tratando de lograr algo que permita control de acceso más granular y permite que el usuario utilice solo un conjunto de credenciales.

En cuanto a la viabilidad, mi primera intento de describir un esquema en el que esto podría lograrse sería hacer las siguientes modificaciones al esquema de Kerberos:

  • Todas las entidades de origen tienen pares de claves y principales que son distintos de los principales utilizados por los usuarios.

  • El principal recibido por un AS puede ser el principal de un usuario o el principal de un usuario que se combina con el principal de una fuente para formar un principal compuesto.

  • Los principios compuestos son, por supuesto, principios válidos y se crean para ser reconocible por lo que cualquiera que sepa sobre este esquema puede reconocer y descomponer el principal para recuperar los ID originales, y hacerlo de tal manera que ambos identificadores puedan ser reconocidos como una fuente o identificación de usuario. Además, los ID de fuente y usuario están limitados para permitir la creación de principios compuestos no ambiguos.

  • La entidad que altera los mensajes del cliente reemplazaría el principal que se envía al AS en ruta con un principal compuesto que tenía un ID de origen codificado en él.

  • Si al AS se le envía un principal compuesto, cifrará la respuesta usando la información compartida del usuario y luego cifrará este mensaje cifrado utilizando la clave pública asociada con el principal del origen. Si no se encuentra el principal del usuario o el principal de la fuente, se obtendrá la misma respuesta que si se hubiera realizado una búsqueda con un principio común.

  • Si al AS se le envía un principal no compuesto, el AS solo usará el principal recibido como principal de un usuario y se comportará de manera normal.

  • La entidad de origen que modificó el mensaje del cliente en ruta al AS descifrará los mensajes que regresan del AS utilizando su propia clave privada, y luego enviar el mensaje al cliente. La entidad no tiene el mensaje de texto claro ya que no conoce el secreto del usuario (ya sea contraseña o clave privada).

No creo que esto altere el protocolo de manera significativa, debería permitir que los clientes ingenuos sigan trabajando y probablemente podría lograrse alterando la lógica que cifra los mensajes para el cliente en el AS. Permitiría que un usuario reciba un conjunto de credenciales y luego el acceso desde un origen particular lo determinará el AS por completo.

Obviamente hay inconvenientes, pero creo que lo anterior sería adecuado en mi caso de uso Las máquinas utilizadas tendrían que ser de confianza, pero esto es lo mismo con Kerberos de todos modos, y los usuarios tendrían que ser confiados para no subvertir los pares de claves de origen, pero esto se puede lograr en mi caso de uso. Por supuesto Cualquier principal no compuesto tendría que otorgar a los usuarios los privilegios mínimos para evitar ataques de escalamiento.

Esto puede haber sido implementado, puede ser parte de Un esquema diferente o puede haber algo más apropiado. a mis necesidades; Soy bastante nuevo en esta área en particular, así que Todavía estoy resolviendo las cosas. Si estoy totalmente descarriado, dilo. He mirado alrededor en busca de algo en este sentido, pero aún tengo que encontrar algo que coincida con lo que estoy describiendo.

    
pregunta Aubrey Stark-Toller 01.12.2016 - 02:44
fuente

1 respuesta

0

Tenga cuidado de no intentar alterar un protocolo de seguridad; Puede ser difícil detectar defectos sutiles. Dando un paso atrás, dijiste:

  

autenticación que identifica a un usuario y el origen de la solicitud de los usuarios

... y ...

  

Mi objetivo principal es mitigar los ataques a las credenciales robadas desde ubicaciones que son entidades de origen válidas.

El protocolo Kerberos permite que los tickets contengan una o más direcciones IP, lo que refleja el origen de la solicitud del usuario. La intención de poner la dirección IP en el ticket es mitigar los ataques a las credenciales robadas, que parece ser exactamente lo que está pidiendo.

Puede haber razones por las que las direcciones de los tickets no funcionen para usted (por ejemplo, si DHCP y / o NAT significan que las máquinas de sus clientes no tienen direcciones fijas), pero debe ser una de las cosas que considere.

También puede buscar entradas Proxiable o Reenviables; sus clientes podrían enviar tickets a un servicio secundario que analice el origen del ticket para decidir cuánto confiar en el ticket.

    
respondido por el Jacob 05.12.2016 - 10:47
fuente

Lea otras preguntas en las etiquetas