Resumen

  • La autenticación diferida de RFC 3118 dependía de un secreto compartido, entregado fuera de banda a un cliente y un servidor DHCP del mismo dominio administrativo.
  • El cliente aún podía aceptar una oferta sin autenticar si la política local lo permitía; el RFC recomendó que pudiera rechazarla y que lo hiciera por defecto.

La opción no creó una identidad universal

DHCP suele recordarse como el protocolo que permite a un equipo conectarse a una red y recibir una dirección y otros parámetros. Esa comodidad también abre una brecha de confianza: un servidor malicioso o activado por error puede proponer una puerta de enlace, un servidor de nombres o una dirección incorrectos. El servidor, por su parte, puede recibir a un cliente que se hace pasar por uno autorizado o que intenta agotar un conjunto de direcciones. Publicada en junio de 2001, RFC 3118 buscó autenticar el origen y el contenido de mensajes DHCP sin rediseñar el protocolo.

La opción 90 exponía el mecanismo en el paquete: selector de protocolo, algoritmo, método de detección de repetición, valor antirrepetición e información de autenticación. Aunque pareciera una sola opción, respondía preguntas distintas: qué procedimiento se usaba, cómo reconocer un mensaje antiguo y qué secreto vinculaba el paquete con su interlocutor.

RFC 3118 distinguió un simple token de configuración de la autenticación diferida. El token ofrecía autenticación débil de la entidad, pero no autenticación del mensaje; el RFC lo describió como una defensa rudimentaria frente a servidores DHCP activados por error. El procedimiento diferido usaba HMAC-MD5 y un secreto compartido. Aquí se describe esa decisión histórica, no se recomienda para sistemas nuevos.

La autenticación empezaba antes del descubrimiento

En el método diferido, el cliente solicitaba autenticación en DHCPDISCOVER. Un servidor elegía un secreto y devolvía información de autenticación en DHCPOFFER. El cliente escogía una oferta y enviaba DHCPREQUEST con el secreto correspondiente; después debía validar una confirmación autenticada. La detección de repetición formaba parte del intercambio, de modo que no bastaba copiar una etiqueta válida de un paquete anterior.

Por tanto, la relación debía existir antes del primer paquete. RFC 3118 decía que el cliente debía recibir la clave por un canal externo. El servidor tenía que conocer, o poder obtener de forma segura, las claves de los clientes autorizados. Si se compartía ampliamente un solo secreto, cualquier poseedor podía hacerse pasar por otro; cuando importaba identificar a cada cliente, el RFC exigía claves únicas. El intercambio en la red dependía así de un sistema de aprovisionamiento que DHCP no definía.

El límite era deliberado. RFC 3118 no resolvía la itinerancia entre dominios administrativos. Se centraba en el uso dentro de un mismo dominio, donde era viable intercambiar secretos por separado, y advertía que el esquema podía escalar mal si un cliente se conectaba a varios dominios. Un MAC confirmaba que el mensaje coincidía con una clave configurada; no inventaba una identidad mundial, un acuerdo de itinerancia ni el derecho a usar una red.

Los relés y la aceptación local también contaban

Los relés DHCP pueden modificar giaddr y hops y añadir información propia. RFC 3118 especificó cómo tratar esos campos al calcular la autenticación, para que el procesamiento legítimo del relé no invalidara la comprobación. Así definió el tránsito por intermediarios, pero no convirtió a cada relé en una autoridad de identidad.

Lo más revelador aparece cuando falta autenticación. Si ninguna oferta tenía autenticación válida, la política local del cliente podía permitir una oferta sin autenticar. El RFC exigía que el cliente pudiera configurarse para rechazarla y recomendaba que ese fuera el valor predeterminado. Si el cliente la aceptaba, aconsejaba informar al usuario y dejar constancia. La seguridad dependía también de la política de respaldo, no solo del MAC incluido en la opción.

Es fácil confundir la presencia de una opción de autenticación con la garantía de que toda configuración aceptada fue autenticada. RFC 3118 advirtió contra esa lectura. Definió un mecanismo y un valor predeterminado prudente, pero dejó a administradores e implementaciones la decisión de confianza local.

El registro no permite saber cuántos clientes y servidores implementaron o configuraron la opción 90, ni cuánto redujo los ataques. Una norma describe un comportamiento posible; la adopción y el resultado requieren pruebas aparte. El aporte histórico de RFC 3118 es más estrecho: la autenticación DHCP siguió siendo un arreglo local, limitado por quién aprovisionaba el secreto, qué servidores y relés estaban dentro del ámbito y si el cliente aceptaba la alternativa sin firma.

Fuentes

  1. https://www.rfc-editor.org/rfc/rfc3118.html
  2. https://www.rfc-editor.org/info/rfc3118
  3. https://datatracker.ietf.org/doc/rfc3118/
  4. https://www.rfc-editor.org/rfc/rfc2131.html
  5. https://www.rfc-editor.org/rfc/rfc2132.html
  6. https://www.rfc-editor.org/rfc/rfc3046.html
  7. https://www.rfc-editor.org/rfc/rfc2104.html
  8. https://www.rfc-editor.org/rfc/rfc1321.html
  9. https://www.rfc-editor.org/rfc/rfc2119.html
  10. https://www.rfc-editor.org/rfc/rfc951.html
  11. https://www.rfc-editor.org/rfc/rfc4361.html
  12. https://www.rfc-editor.org/rfc/rfc6842.html
  13. https://www.rfc-editor.org/rfc/rfc8415.html
  14. https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml