RFC 3112: una contraseña coincidente no era autenticación

Resumen

RFC 3112 dividió el valor derivado de contraseña en esquema, información del esquema y valor de autenticación. Sus reglas podían devolver TRUE, FALSE o Undefined, pero esas respuestas describían una comparación, no una asociación LDAP autenticada.
El propio RFC exigía Bind para autenticar. Como el atributo admitía varios valores, quien pudiera escribirlo podía añadir otra contraseña aceptada sin desactivar la que el usuario legítimo seguía usando.

Un resultado verdadero antes de la autenticación

Un cliente entrega una contraseña a una regla de coincidencia. El servidor encuentra un valor, identifica el esquema y la sal, calcula el derivado y responde verdadero. El secreto coincide. Sin embargo, el cliente todavía no se ha autenticado ante el directorio.

Esa separación es el núcleo de RFC 3112, publicado como Informational en mayo de 2001. «LDAP Authentication Password Schema» propuso almacenar información derivada de una contraseña en lugar del secreto que el uso contemporáneo de userPassword daba por disponible. Definió sintaxis, reglas de matching, un atributo de capacidades en la DSE raíz y una clase auxiliar. Después puso un límite explícito a su propia comodidad: un authPasswordMatch satisfactorio obtenido mediante Compare o Search no bastaba para acceder. Había que ejecutar Bind.

La aparente contradicción desaparece al separar estados. La regla de matching decide si una cadena presentada concuerda con alguno de los valores almacenados bajo su método declarado. Bind decide si el servidor acepta una identidad de autenticación para esa asociación LDAP. La política de acceso decide qué puede hacer la identidad de autorización resultante. La aplicación que consulta el directorio sigue decidiendo su acción final.

Si el registro resume todos esos pasos como «login correcto», ya no permite reconstruir nada. Una coincidencia puede existir sin Bind. Bind puede tener éxito y una modificación ser denegada. Una lectura LDAP permitida no prueba que una transferencia, compra o cambio posterior se completara.

El valor nombraba su propio mecanismo

authPasswordSyntax contenía tres componentes sensibles a mayúsculas y minúsculas, separados por signos de dólar: scheme, authInfo y authValue. El primero nombraba el mecanismo; el segundo solía llevar una sal codificada en base64; el tercero, el resultado derivado.

La estructura hacía posible que un directorio guardara mecanismos distintos y que el servidor anunciara cuáles entendía. RFC 3112 definió MD5 y SHA1. Los nombres privados debían usar X- o un OID. supportedAuthPasswordSchemes, presente únicamente en la DSE raíz, publicaba las capacidades declaradas.

Publicar una capacidad no demostraba su ejecución. El anuncio no decía qué esquema había seleccionado el servidor para una autenticación, qué entrada contenía cada valor, quién lo escribió, si la sal era única, si la comparación viajó cifrada ni si Bind terminó correctamente. La DSE describía posibilidad, no trazabilidad.

También es necesario conservar la fecha. Los esquemas MD5 y SHA-1 de RFC 3112 aplicaban un digest a la concatenación de contraseña y sal. La sal debía medir al menos 64 bits y las implementaciones tenían que soportar hasta 128 bits. Son definiciones históricas, no recomendaciones actuales. RFC 8018 convirtió sal y número de iteraciones en parámetros explícitos de criptografía basada en contraseñas; RFC 9106 describió la función de memoria dura Argon2 y prefirió Argon2id para hashing y derivación. Esos textos no alteran lo que decía el RFC de 2001, pero impiden llamar «seguro» a un valor sin nombrar el esquema y sus costes.

Igualdad de representación, prueba de secreto y Bind

authPasswordExactMatch comparaba los componentes ya codificados. Si una entrada tenía exactamente el mismo esquema, authInfo y authValue, respondía verdadero; si ninguna coincidía, falso; en otro caso, indeterminado. Era una igualdad entre representaciones.

authPasswordMatch aceptaba una contraseña mediante un filtro extensible. Cada valor se probaba conforme a su propio esquema. Bastaba una coincidencia para devolver verdadero; el fracaso de todas daba falso; la imposibilidad de completar el test producía Undefined.

Ninguno de esos estados identificaba a la persona que escribía. Verdadero no demostraba quién controlaba el canal ni si tenía derecho a probar el atributo. Falso no demostraba que la entrada fuera la correcta ni que no existiera otro almacén de credenciales. Indeterminado no era «contraseña equivocada»: conservaba precisamente la ausencia de una conclusión.

El mandato de usar Bind impedía que esa incertidumbre ganara autoridad por accidente. RFC 4511 describió más tarde el resultado de Bind en la revisión del protocolo, y RFC 4513 separó identidad de autenticación e identidad de autorización. Esta última podía derivarse de la primera o, con un mecanismo adecuado, ser solicitada por separado si el servidor permitía la representación.

Por eso ni siquiera Bind equivalía a permiso total. Autenticar establecía quién había aceptado el servidor en la asociación. Autorizar decidía si esa identidad podía leer, comparar o modificar un objeto. El servicio de negocio conservaba otra decisión propia.

Un atributo con más de una llave

authPassword admitía varios valores. Para los esquemas elegidos, el servidor debía considerar los valores pertinentes, y uno solo podía validar la contraseña. Eso ayudaba a migrar formatos o mantener un solapamiento controlado. También convertía el permiso de escritura en una capacidad de crear otra vía de entrada.

RFC 3112 señala el ataque: quien consigue escribir el atributo puede añadir un valor sin deshabilitar la contraseña auténtica del usuario. La víctima sigue accediendo y no ve un reinicio. La credencial extra permanece como puerta silenciosa.

Una foto final de la entrada no explica la procedencia. Dos valores no dicen quién añadió cada uno, qué política lo permitió, si hubo una operación de cambio o qué valor debía retirarse. La prueba tiene que seguir cada alta, reemplazo y borrado, la identidad del escritor, su autorización, el esquema, los parámetros, la replicación y la fecha de retirada.

RFC 3062 ya había definido la operación extendida Password Modify. Permitía al servidor determinar el objetivo bajo reglas controladas, aceptar o generar un secreto y escoger la forma de almacenarlo. RFC 3112 podía utilizarse con esa operación, pero el atributo por sí solo no era un sistema completo de ciclo de vida.

Además, el servidor podía combinar authPassword, userPassword y un almacén externo. Ver o borrar un valor no describía necesariamente todas las rutas disponibles para autenticar.

Un derivado debía protegerse como el secreto

El documento no permitía considerar pública una función unidireccional. Recomendaba proteger los valores como contraseñas en claro: fallos del algoritmo, errores de implementación o ataques offline podían convertir la filtración en acceso. Desaconsejaba transferirlos sin un transporte que garantizara confidencialidad.

La aserción enviada a authPasswordMatch también era sensible. Era un intento de contraseña transportado hasta el servidor. Sin protección podía filtrarse; sin control de acceso y límites podía convertirse en un oráculo de adivinación.

El coste de cálculo introducía otra tensión. Un mecanismo costoso eleva el precio de probar contraseñas, pero también permite que un cliente consuma CPU del servidor. Limitación de tasa, concurrencia, plazos y permiso para comparar forman parte de la política real. Un nombre de esquema no prueba que esas defensas existan.

El contexto cambió, la frontera sobrevivió

RFC 3112 hablaba de userPassword tal como lo presentaban RFC 2251 y RFC 2256 en 1997. Esa comparación no debe proyectarse eternamente. RFC 4519 aclaró después que los valores de userPassword no tenían que ser texto claro ni servir necesariamente para Bind. Las implementaciones desarrollaron convenciones propias.

Tampoco el estatus Informational prueba adopción. Los registros del RFC Editor y el IETF Datatracker prueban publicación e historia. RFC 2252 da el lenguaje de esquema; RFC 2829 y RFC 4513 colocan la contraseña dentro del modelo de seguridad; RFC 4511, RFC 4517 y RFC 4519 muestran la revisión del protocolo, reglas y atributos. Ninguna fuente demuestra que un directorio concreto desplegara RFC 3112.

Lo duradero es la cadena de evidencias. Para sostener que alguien «inició sesión», hay que conservar la entrada y su historial de mutaciones; esquema, sal y parámetros; el derecho de Compare o Search; el canal; la solicitud y su estado verdadero, falso o indeterminado; los valores probados; la solicitud Bind y su respuesta; las identidades de autenticación y autorización; la operación siguiente y el resultado visible de la aplicación.

El password podía coincidir exactamente. RFC 3112 sabía que esa coincidencia no tenía autoridad para hablar en nombre de Bind.

La contraseña coincidió. El usuario aún no estaba autenticado: RFC 3112

Por qué importa

Resumen

Un resultado verdadero antes de la autenticación

El valor nombraba su propio mecanismo

Igualdad de representación, prueba de secreto y Bind

Un atributo con más de una llave

Un derivado debía protegerse como el secreto

El contexto cambió, la frontera sobrevivió

Fuentes

Contexto ampliado del perfil

Strategic Circle

Leadership Alliance

Informe de Strategic Circle

Informe de Leadership Alliance