Resumen

  • El borrador TLS PAKE declara que server_identity es independiente del SNI; añadir certificados crea otro modo de autenticación, no una traducción automática entre nombres.
  • Un Finished correcto demuestra posesión de claves para ese transcript, pero no prueba titularidad legal, autorización de la cuenta, integridad del alta ni resultado de la operación.

El cliente abrió servicio.example, ofreció una identidad PAKE distinta y recibió un certificado para un nombre gestionado por otra plataforma. La contraseña era correcta. Los tres nombres no señalaban a la misma autoridad.

La conexión terminó, pero el registro de auditoría sólo guardó «autenticación mutua correcta».

draft-ietf-tls-pake-02, publicado el 6 de julio de 2026 y con vencimiento el 7 de enero de 2027, propone integrar intercambios autenticados por contraseña en TLS 1.3. Sigue siendo un Internet-Draft Informational activo del grupo TLS. No es RFC, asignación definitiva, prueba de despliegue ni conclusión de seguridad; el propio texto reconoce que el análisis significativo aún está pendiente.

El problema empieza antes del nombre

El PSK ordinario de TLS 1.3 necesita entropía alta. Usar directamente una contraseña humana permite comprobar candidatos a partir del binder. El borrador introduce la extensión pake, negocia un esquema y combina el secreto PAKE con el intercambio efímero normal dentro del calendario de claves.

El cliente envía una pareja client_identity/server_identity común a todas sus ofertas. Cada PAKEShare indica un esquema distinto. El servidor encuentra una opción compatible y busca material de registro asociado a esa pareja.

«Compatible» no significa «registrado». Una implementación puede conocer SPAKE2+ o CPace sin disponer del verificador de ese usuario. Incluso puede simular una respuesta cuando el registro no existe para no convertir el primer vuelo en un oráculo de cuentas.

Esta separación obliga a registrar al menos tres hechos: algoritmo común, registro localizado y Finished validado. El éxito del primero no adelanta los otros dos.

server_identity no es SNI

El borrador dice expresamente que la identidad del servidor dentro de PAKE es disjunta del Server Name Indication. SNI participa en el enrutamiento del servicio y suele intervenir en la selección del certificado. La identidad PAKE forma parte del contexto criptográfico y de la búsqueda del registro.

Nada impide que una organización decida alinearlas, pero esa es una regla local. El protocolo no la crea. Un gateway puede terminar TLS para varios servicios, un nombre PAKE puede representar un dominio administrativo y el certificado puede cubrir un conjunto de nombres. La semejanza textual no prueba identidad de control.

El recibo debe conservar valores y políticas por separado: SNI enviado, referencia validada del certificado, identidad PAKE, cuenta resultante y decisión de autorización. Si sólo queda un campo principal, ya no se puede saber qué vínculo fue demostrado y cuál fue configurado.

El certificado añade una afirmación distinta

El cliente puede enviar signature_algorithms junto a PAKE. Si el servidor elige PAKE en ese caso, debe aportar Certificate y CertificateVerify. Así se combinan conocimiento del secreto y autenticación por certificado.

Sin esa solicitud, PAKE puede sostener la autenticación de la relación sin la misma prueba PKI. Eso no es necesariamente un defecto: algunos entornos provisionados quieren precisamente esa propiedad. Sí es un error describir ambos modos con la misma etiqueta pública.

Un certificado válido tampoco autoriza una operación. Vincula una clave a una identidad de referencia bajo una política de validación. La aplicación aún decide si la cuenta puede leer, modificar o transferir un recurso. PAKE, certificado y autorización forman tres controles, no tres sinónimos.

La respuesta simulada conserva la ambigüedad

Cuando no hay registro, el servidor puede seleccionar un esquema y enviar una participación aleatoria plausible. El cliente terminará sin un Finished válido. El objetivo es que el atacante no sepa de inmediato si falló la identidad o la contraseña.

Por eso ServerHello no prueba que la cuenta exista. Tampoco una alerta tardía prueba que la simulación sea indistinguible: latencia, tamaño, consultas a la base, caché, CPU y límites de intentos pueden filtrar diferencias.

Una auditoría que cuenta respuestas PAKE como usuarios reconocidos mide ramas de protocolo. Para contar autenticaciones debe llegar a Finished del cliente; para contar cuentas válidas necesita una fuente de registro protegida, no inferencia desde la red.

Finished no concede derechos

El secreto PAKE se combina con (EC)DHE, y Finished confirma el transcript. El servidor sólo ha autenticado al cliente después de verificar el Finished del cliente y no debería enviar datos de aplicación antes.

Ese punto de no anticipación es operativo. Una respuesta temprana personalizada puede revelar la existencia de la cuenta o información protegida aunque la conexión termine luego. La hora de la primera carga útil debe compararse con la hora de validación.

Después de Finished queda el control de negocio. La contraseña puede pertenecer a un equipo compartido, haber sido recuperada mediante un proceso débil o seguir activa tras una baja. La posesión criptográfica de hoy no prueba legitimidad administrativa.

Un PAKE externo necesita correlación explícita

Los esquemas internos caben en ClientHello y ServerHello. Si un PAKE necesita más rondas, puede ejecutarse fuera de TLS y su salida importarse como PSK mediante RFC 9258.

El segundo handshake prueba la clave importada, no narra el primero. Hay que enlazar hash del transcript PAKE, roles, identidades, contexto de channel binding, identidad importada y conexión TLS consumidora. Sin ese enlace, una sesión PSK correcta podría estar unida a la ceremonia equivocada.

La diversificación de RFC 9258 reduce confusiones entre protocolos y KDF. No verifica que la aplicación haya asignado el nombre correcto ni que el operador conserve la evidencia. El control final sigue siendo de quien construye la integración.

La protección cuántica tiene dos objetos

Un key share TLS híbrido o poscuántico puede mantener confidencial el tráfico grabado. Si el PAKE seleccionado es clásico, un adversario futuro puede atacar por separado sus mensajes y recuperar una contraseña reutilizada.

La diferencia cambia el riesgo: quizá no lea la sesión antigua, pero puede suplantar al usuario en una sesión futura hasta que la credencial rote. El panel debe mostrar «confidencialidad del tráfico» y «longevidad del secreto de autenticación» por separado.

OQUAKE, OQUAKE+ y la combinación externa híbrida se describen en borradores que siguen evolucionando. Son alternativas de investigación, no una casilla que permita declarar cerrada la transición.

El alta es una autoridad ausente del transcript

El borrador presupone contraseñas o verificadores previamente provisionados. No define cómo se comprobó la identidad, quién autorizó un reset, cómo se migran esquemas, cuándo se destruye el registro anterior ni cómo se vincula la cuenta a permisos.

Por eso un transcript impecable puede confirmar un alta equivocada. La organización necesita un recibo versionado del registro y de cada rotación. El protocolo de sesión no puede responder quién tenía autoridad para crear la relación.

La conclusión no es que PAKE sea débil. Es que mejora una pieza concreta: evita usar una contraseña de baja entropía como PSK bruto y puede ocultar la existencia del registro. Su fuerza depende de no inflar esa pieza hasta convertirla en identidad universal.

Fuentes