Resumen

  • SPAKE y la derivación ligada a la transcripción impiden normalmente que un KDC impostor pruebe contraseñas offline. Anunciar PA-SPAKE no demuestra que el intercambio llegara a esa validación.
  • Si el cliente vuelve al timestamp cifrado después del fallo, un observador pasivo puede atacar offline el valor introducido. Ni siquiera el éxito de la preautenticación acredita la autorización de una aplicación.

La compatibilidad suele presentarse como una red de seguridad. Cuando el método nuevo falla, el cliente recurre al antiguo y el usuario puede seguir trabajando. En RFC 9588, esa misma continuidad puede devolver al atacante una capacidad que SPAKE acababa de quitarle.

El mecanismo está diseñado para que un adversario activo, fingiendo ser el KDC, no obtenga un verificador offline de la contraseña. Pero el atacante puede intentar degradar al cliente hacia el timestamp cifrado. Si un error de escritura provocó el fallo de SPAKE y luego se usa el método antiguo, la captura permite probar ese error sin volver a hablar con el KDC. Una letra equivocada no elimina el patrón humano del secreto.

La lección no es que SPAKE mienta. Es que la política de recuperación participa en la propiedad criptográfica.

Negociar no equivale a validar

IANA asigna a PA-SPAKE el tipo 151. El KDC anuncia soporte, el cliente enumera grupos y el KDC selecciona uno. Son recibos de negociación, no prueba de que ambas partes compartan las claves derivadas.

Además, los primeros mensajes contienen texto no autenticado. Sin FAST, la lista de factores permanece visible y solo gana integridad cuando la respuesta se verifica. PA-SPAKE-HINT queda fuera de la transcripción y no reemplaza el intercambio real.

El mecanismo termina cuando el KDC descifra la respuesta, valida los factores requeridos y ambos lados fortalecen la clave de respuesta con K'[0]. No existe una confirmación final PA-SPAKE desde el KDC; el cliente aún depende de la respuesta cifrada del KDC para autenticarlo.

El fallback elige el riesgo efectivo

RFC 9588 aconseja una opción por realm para desactivar el timestamp cifrado. Esa decisión vale más que un porcentaje de «soporte SPAKE». Una organización puede desplegar la capacidad y conservar el mismo ataque en la rama que se ejecuta cuando algo sale mal.

Tampoco desaparece el guessing online. El KDC observa fallos y debe aplicar controles como rate limiting. Contar solo handshakes SPAKE correctos deja fuera los fallos, degradaciones y límites que definen el camino real.

Autenticación no es autorización

El éxito demuestra conocimiento de la clave de respuesta inicial y los factores realmente validados. SF-NONE significa que no hubo segundo factor; SPAKE no convierte por sí mismo el acceso en MFA.

Después siguen el KDC-REP, la emisión y uso del ticket de servicio y la autorización propia de la aplicación. La transcripción protege el cuerpo de la petición Kerberos, pero no concede un rol, no aprueba un pago ni confirma la entrega de un recurso.

La implementación también forma parte del control: puntos válidos, escalares aleatorios no reutilizados, constantes sin logaritmos discretos conocidos y ausencia de canales laterales. Un KDC sin estado puede guardar el escalar y la transcripción en PA-FX-COOKIE; el cookie necesita confidencialidad, integridad, caducidad y vínculo con el principal. El RFC tampoco promete forward secrecy de forma general.

Fuentes