Resumen

  • En el modo mutuo, el cliente firmaba el desafío del servidor junto con un valor aleatorio que acababa de elegir. La firma final del servidor cubría ambos, pero añadía un tercero porque el cliente ya conocía el desafío inicial antes de escoger el suyo.
  • Ese tercer valor vinculaba la respuesta del servidor con una aportación aleatoria nueva. No convertía el mecanismo en un canal seguro: RFC 3163 no proporciona integridad ni confidencialidad y advierte que siguen siendo posibles los ataques activos.

Una repetición solo aparente

El intercambio parece duplicar controles. El servidor envía un desafío aleatorio, el cliente firma un transcript que lo incluye y, después, el servidor firma otro transcript que también lo incluye. ¿Para qué necesita el token final del servidor un tercer valor?

RFC 3163, «ISO/IEC 9798-3 Authentication SASL Mechanism», responde atendiendo al orden de las decisiones. No importa cuántos mensajes haya, sino quién conocía cada desafío cuando eligió su propio número aleatorio. Ese orden determina qué puede acreditar una firma sobre la sesión.

El memorando Experimental de agosto de 2001 define dos familias. 9798-U-<algorithm> autentica al cliente ante el servidor. 9798-M-<algorithm> añade autenticación mutua: el cliente firma un desafío del servidor y este firma un desafío del cliente. Ambos modos usan firmas de clave pública y certificados X.509; el procedimiento descrito incluye procesamiento de la ruta del certificado.

El orden de los desafíos

En los dos modos, el servidor empieza generando R_B. Después, el cliente elige R_A. Su TokenAB incluye datos del certificado y una firma sobre R_A y R_B; puede incluir además un identificador del servidor. El servidor comprueba la firma, verifica que el valor devuelto R_B coincide con el desafío que envió y valida el identificador, si está presente.

En la autenticación unilateral, ese token del cliente completa el intercambio principal. El modo mutuo agrega una respuesta del servidor: TokenBA2 lleva el certificado del servidor y una firma sobre R_A, R_B y un nuevo valor, R_C. El cliente verifica el certificado y la firma, comprueba que los dos valores anteriores coinciden con las etapas previas y revisa el identificador opcional del cliente.

La sección 7 explica por qué aparece R_C. Incluir R_A en los datos que firma el cliente impide que el servidor obtenga esa firma sobre datos que hubiera elegido antes de comenzar el mecanismo. La dirección inversa no es simétrica: el cliente conocía R_B antes de escoger R_A. El servidor debe incluir R_B en su firma para que el cliente pueda comprobar el transcript, pero ese valor, por sí solo, no ofrece la misma protección al servidor. Por eso RFC 3163 añade R_C al TokenBA2 firmado por el servidor.

Este es el razonamiento concreto del RFC, no una demostración general contra todo intermediario, repetición o atacante activo. Los valores aleatorios deben generarse con un generador criptográficamente robusto; si son predecibles, el mecanismo puede ser atacado. El tercer valor responde a la brecha temporal descrita, no arregla todas las propiedades que quedan fuera del transcript.

Una firma no protege la sesión

El límite está escrito de forma explícita. RFC 3163 dice que el mecanismo solo aporta autenticación. No protege la integridad de los mensajes posteriores ni cifra su contenido. La sección de seguridad afirma que solo ofrece protección frente a la escucha pasiva y señala que los ataques activos, incluido el secuestro de sesión, siguen siendo posibles. La nota de la IESG es más directa: el mecanismo asume la complejidad de la PKI y descarta la integridad de cada transmisión, mientras que TLS puede aportar ese efecto con beneficios de integridad.

Los certificados no fusionan esas capas. authID puede señalar una identidad de control de acceso distinta de quien firma el certificado. La aceptación de una ruta de certificados, la autenticación del mecanismo, la correspondencia de identidad y la autorización de una aplicación son decisiones separadas. Una firma válida verifica datos cubiertos bajo una clave; no decide por sí misma qué debería permitir la aplicación.

El ejemplo IMAP del RFC tampoco muestra el intercambio mutuo. Es un ejemplo de autenticación unilateral 9798-U y especifica que Base64 y el prefijo + pertenecen al perfil IMAP, no al mecanismo SASL. Es una ilustración, no una prueba de despliegue ni interoperabilidad.

La Nota 20 de Lu Heng funciona aquí como lente interpretativa: separar lo que el protocolo comprueba de afirmaciones más amplias sobre identidad o autoridad. La correspondencia entre desafíos y las firmas verificadas pertenecen al transcript; la protección del canal y los permisos de la aplicación dependen de otros controles. Esa lectura no se atribuye a los autores de RFC 3163.

Fuentes

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. Ficha del RFC Editor para RFC 3163
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. Registro de mecanismos SASL de IANA
  12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile