Resumen

  • RFC 3962 representó el coste de PBKDF2 mediante cuatro octetos sin signo y en orden de red: el valor explícito 00 00 00 00 equivalía a 4.294.967.296 iteraciones; la ausencia del campo equivalía a 4.096 solo cuando el KDC había podido enviarlo.
  • Un recuento falso y alto podía agotar al cliente, mientras que uno falso y bajo podía abaratar la búsqueda del atacante. Había que registrar procedencia, autenticidad y límites, no solo el número final.

En muchos programas, cero cumple demasiados papeles. Puede ser una cantidad, un indicador de “no configurado”, un resultado vacío o la orden de tomar un valor predeterminado. RFC 3962 eliminó esa comodidad en el perfil AES de Kerberos: cuatro octetos cero constituían una instrucción explícita y extraordinariamente costosa.

El parámetro de conversión de cadena a clave era un entero de cuatro octetos, sin signo y en orden big-endian. El entero indicaba las iteraciones de PBKDF2. Para reservar todo el rango, el patrón nulo significaba 4.294.967.296 vueltas. Por eso el mínimo expresable era uno.

No recibir el campo era otra cosa. Cuando el KDC ya había tenido la oportunidad de incluirlo, su ausencia se interpretaba como 00 00 10 00, es decir, 4.096. El RFC aclaró que aquello no recomendaba 4.096 para las claves de todos los principales ni para la preautenticación optimista. Solo definía una omisión concreta.

El dato empezaba antes de sus bytes

Un modelo de datos fiel necesitaba conservar la presencia del campo además de su contenido. Si una API transformaba el arreglo nulo en null, o si una base rellenaba el nulo con cero, modificaba el coste en un factor de 1.048.576. La procedencia no era metadato decorativo; decidía qué operación debía ejecutar el cliente.

RFC 3962 apareció en febrero de 2005 como una aplicación del marco de RFC 3961. Definió AES con bloques de 128 bits, claves de 128 o 256 bits, CBC con robo de texto cifrado y HMAC-SHA1-96. Los tipos de cifrado 17 y 18 y los tipos de suma 15 y 16 permanecen en el registro de parámetros Kerberos de IANA. Estar registrado demuestra asignación y referencia, no uso en una sesión.

La ruta desde la contraseña aplicaba PBKDF2 a la frase y la sal, y después derivaba la clave con la constante kerberos según RFC 3961. RFC 2898 era la referencia de PBKDF2 en PKCS #5; RFC 8018 publicó después su revisión. El tamaño de una clave AES-256 no convierte una contraseña previsible en un secreto de 256 bits. Las iteraciones encarecen la prueba, pero no añaden diversidad a las elecciones humanas.

El multiplicador no conocía aliados

PBKDF2 cobraba la misma tarifa por cada intento, fuera legítimo o hostil. Multiplicar las vueltas elevaba el coste del diccionario del atacante y también la espera del usuario que sí conocía su contraseña. La protección debía elegirse con los recursos de ambas partes en mente.

El RFC mostró entonces una pinza poco intuitiva. Si un intruso falsificaba una respuesta del KDC con un número enorme, podía mantener ocupado al cliente calculando una clave equivocada. Para limitar esa denegación de servicio, una implementación podía rechazar valores por encima de un máximo; el documento decía que ese máximo, si existía, no debía ser inferior a 50.000. Para el caso de miles de millones, también era sensato permitir cancelar el trabajo.

Si el intruso bajaba el número, obtenía otra ventaja. Podía observar la respuesta del cliente y probar candidatas con menos coste. De ahí la conveniencia de un mínimo local. La política correcta era una ventana aceptable más una evaluación del origen, no la obediencia ciega a la red y tampoco la persecución del mayor valor posible.

Pensemos en una auditoría que solo guarda 4096. No revela si el campo faltó, si esos octetos llegaron de un KDC autenticado, si procedían de una respuesta manipulable, si los aportó una caché o si eran configuración para una ruta optimista. Tampoco dice si se validaron los límites antes de consumir CPU. Sin esos enlaces, un número exacto sigue siendo evidencia incompleta.

Ahorrar un viaje obligaba a gobernar la conjetura

La preautenticación optimista permitía fabricar y enviar un timestamp protegido antes de consultar al KDC. Ahorraba un intercambio cuando el cliente acertaba el parámetro. Pero, sin información adicional, el cliente solo podía adivinar el número de iteraciones.

RFC 3962 descartó incluso una heurística aparentemente razonable: reutilizar lo que funcionó para el mismo principal unas horas antes. Los administradores podían elevar el coste con el tiempo, de modo que el recuerdo ya no representaba la política actual. En lugar de fijar un número universal, el texto recomendó configuración local dentro de las cotas de seguridad.

La enseñanza no consiste en trasladar cifras de 2005 al presente. Las prestaciones y la economía del descifrado cambian. Lo perdurable es que una conjetura requiere dueño, fecha y mecanismo de actualización. Cuando una optimización evita observar al KDC, debe reconocer que está sustituyendo evidencia fresca por política.

La derivación no emitía una autorización

Terminar PBKDF2 solo producía una clave candidata. RFC 4120 define el resto de Kerberos V5: tickets, autenticadores, frescura y manejo de repetición. El cálculo no demuestra por sí solo que la contraseña fuera correcta, que el KDC aceptara la preautenticación, que el ticket siguiera vigente o que la aplicación autorizara la acción.

RFC 4537 distinguió después los tipos ofrecidos del tipo elegido según la política del servidor. RFC 6113 amplió el marco de preautenticación. RFC 8009 añadió perfiles AES con HMAC-SHA2 y RFC 8429 desaconsejó algoritmos antiguos. Ningún cambio convirtió un identificador, una iteración o una clave calculada en prueba de acceso autorizado.

El propio modo de robo de texto cifrado marcaba otra frontera: al evitar relleno, conservaba la longitud exacta del mensaje. Si la longitud era sensible, la capa superior debía ocultarla. Aumentar PBKDF2 no solucionaba esa exposición; era un control para otro problema.

Una cadena de evidencia útil separaría: existencia del campo, octetos originales, valor interpretado, origen y autenticidad, mínimos y máximos locales, tipo de cifrado, procedencia de la sal, versión de biblioteca, tiempo, recursos y cancelación. Después guardaría por separado el resultado de preautenticación, ticket, repetición, autorización y servicio. Ni contraseña ni clave secreta deberían registrarse.

La ficha del RFC Editor, el historial de Datatracker y la búsqueda de erratas documentan el estándar; la última no devolvía coincidencias al capturarse. Eso informa sobre el expediente, no certifica cada implementación.

El gran número de RFC 3962 atrae la mirada, pero su herencia está en una disciplina de datos: cero, ausencia y predeterminado no son sinónimos. Si el sistema borra cuál de ellos ocurrió, también borra quién ordenó el coste y por qué.

Fuentes