Resumen

  • RFC 2444 sustituyó el análisis improvisado de contraseñas de un solo uso en cada aplicación por un mecanismo SASL con formatos de intercambio definidos.
  • El mecanismo autenticaba con una respuesta OTP, pero no ofrecía capa de seguridad, privacidad de sesión, autenticación del servidor ni protección frente a ataques activos.

A finales de los años noventa, un cliente de correo podía añadir autenticación de la manera que dictara la práctica local de cada protocolo. RFC 2444 señaló esa costura: OTP se incorporaba de forma improvisada, con análisis heurístico. El documento le asignó un mecanismo dentro de Simple Authentication and Security Layer (SASL), de modo que un protocolo de aplicación pudiera solicitar un intercambio definido en vez de inventar su propio analizador de contraseñas OTP.

Ese paso mejoró la interoperabilidad. No prometió proteger toda la conexión. RFC 2222 ya distinguía la autenticación de la negociación opcional de una capa de seguridad. RFC 2444 fue aún más explícito: el mecanismo OTP no proporciona capa de seguridad. Su apartado de seguridad descarta privacidad de sesión, autenticación del servidor y protección ante ataques activos. Por eso, una respuesta de «autenticación correcta» puede cerrar un intercambio mientras el canal que transporta los siguientes comandos sigue siendo otro objeto, con protecciones distintas.

RFC 2444 perfila el sistema OTP de RFC 2289 y las respuestas ampliadas de RFC 2243. El servidor debe admitir cuatro formas: hex, word, init-hex e init-word. Las dos primeras transportan una respuesta; las formas init- también reinician la secuencia. El documento exige compatibilidad con MD5 y recomienda SHA-1. El cliente debe señalar cuando el número de secuencia es demasiado bajo y debería ofrecer una vía para reiniciarlo. Cada uso actualiza la entrada del usuario en la base de autenticación. Así se concreta qué deben hacer cliente y servidor, pero la compatibilidad y el mantenimiento del estado pasan a ser parte del contrato operativo.

El apartado de uso previsto menciona un cliente no fiable, como un quiosco. Si se captura un OTP, ese cliente solo debería disponer de una oportunidad para actuar en nombre del usuario; esa promesa es más limitada que proteger la sesión posterior. El mismo apartado reconoce que una base de autenticación comprometida puede sufrir ataques de diccionario, aunque no tenga que equivaler a una base de contraseñas en texto claro. El mecanismo no queda por ello a salvo: RFC 2444 también menciona el ataque pasivo de diccionario y exige protegerse contra la condición de carrera descrita por la especificación OTP subyacente.

SASL separa además la identidad de autenticación de la identidad de autorización. La primera aporta las credenciales; la segunda indica los privilegios que se solicitan. Pueden ser distintas, como cuando un agente actúa por otra persona. Si la identidad de autorización está vacía, el servidor puede derivarla de las credenciales. Una respuesta OTP correcta resuelve, por tanto, una pregunta del intercambio, no toda la política de acceso.

El nombre del mecanismo, la sintaxis del desafío, la codificación de tokens del protocolo anfitrión, la protección del transporte, la identidad del servidor y la decisión de autorización no deben reducirse a una sola etiqueta de «autenticado».

RFC 2444 actualiza la especificación SASL de 1997 y marca como obsoleto el uso previsto del mecanismo S/Key para SASL. RFC 4422 reemplazó después aquel marco inicial; RFC 5034 documenta un perfil POP3 y RFC 5802 especifica otro mecanismo, SCRAM. Son hitos para delimitar el marco, no pruebas de que RFC 2444 se desplegara de forma universal ni de que sus recomendaciones criptográficas de 1998 sigan siendo adecuadas. Un estándar fija diseño y comportamiento normativo; no es un censo de implementaciones.

Su logro histórico fue acotado y concreto: los protocolos podían pedir un mecanismo OTP con nombre, en vez de analizar una convención local. El texto deja el trabajo restante a la vista. Quien diseña el protocolo debe definir cómo viajan los tokens SASL; quien implementa el servidor debe mantener coherente la secuencia; quien opera el servicio debe proteger lo que ocurre después del acceso; y la aplicación debe decidir qué permisos corresponden a esa identidad. «De un solo uso» describía el límite de reutilización de la respuesta. No describía la seguridad de la sesión.

Fuentes