Resumen

  • El borrador EAP-PPT de EMU, actualizado el 30 de septiembre, ya no atribuye a Privacy Pass la generación de MSK o EMSK. La versión 03 derivaba 128 octetos del exportador TLS del túnel y los dividía en dos claves; la versión 04 prohíbe informar esas claves como material del método interno. Sigue siendo un Internet-Draft, no un RFC.
  • Presentar un token demuestra su posesión y permite que el servidor lo acepte. No crea un secreto compartido entre el par y el servidor EAP-PPT. La nueva sección de seguridad explica por qué la autenticación del servidor del túnel, no una supuesta clave del token, es la defensa principal frente a un posible intermediario que retransmita el intercambio.

Imaginemos una conexión en la que el usuario entrega una credencial de un solo uso dentro de un túnel TLS. Si el sistema entrega finalmente una clave al equipo de acceso, sería tentador atribuirla a la credencial. Ese salto es precisamente lo que corrige draft-ietf-emu-eap-ppt-04. La propuesta utiliza un token Privacy Pass para autorizar al par dentro de un método EAP basado en un túnel con servidor autenticado. Su estado en Datatracker es I-D Exists y su objetivo declarado es llegar a un estándar propuesto; nada de ello acredita todavía despliegue, aprobación final o un fallo real.

La revisión anterior sí contenía una fórmula de claves. El exportador de la sesión TLS externa producía 128 octetos con un contexto que incluía el tipo EAP y el valor del token; los primeros 64 se llamaban MSK y los siguientes 64, EMSK. La revisión 04 elimina la sección de generación y establece que EAP-PPT no deriva ninguna de las dos. También dice que una implementación no debe comunicar material de clave propio de EAP-PPT al método de túnel que lo transporta. La fuente de la clave que recibe el autenticador es el método EAP externo, no el token presentado dentro.

La razón no depende de una debilidad inventada en Privacy Pass. Es una cuestión de actores. Para un tipo de token, el servidor verifica con la clave pública del emisor; para otro, con material compartido entre emisor y servidor. El par que entrega el token no comparte con el servidor EAP-PPT un secreto nuevo derivado de esa comprobación. En cambio, quien termina el túnel ya conoce la sesión TLS y puede calcular lo que sale de su exportador. Si ese resultado se contabilizara como una clave independiente del método interior, la operación de cryptographic binding podría aparentar que dos participantes eran el mismo sin aportar la prueba adicional que se supone que distingue un extremo del otro.

El texto nuevo evita una conclusión igual de errónea en sentido contrario. Que EAP-PPT no contribuya una clave no significa que el túnel carezca de claves ni que no haya autenticación del servidor. La tabla de garantías marca «no» para derivación de claves y vinculación criptográfica de EAP-PPT, pero «sí» para channel binding, una comprobación diferente de la información de red. El método externo conserva su propio trabajo de protección; el interno acepta o rechaza la credencial. Mezclar esos estados puede hacer que una decisión de acceso parezca una prueba de identidad del túnel.

La nueva sección 9.4 expone el coste de esa confusión. Describe cómo un atacante podría conseguir que el par aceptase un certificado suyo, recibir el token en un túnel, reenviar el intercambio interior a un servidor auténtico y canjearlo para obtener acceso. Por eso pide verificar el certificado con anclas de confianza configuradas para la red concreta y comprobar que la identidad del servidor coincide con la prevista; desaconseja aceptar el certificado al primer uso o dejar que el usuario ignore un fallo. La colocación conjunta de funciones, el channel binding, un token de vida corta y la detección del doble gasto acotan consecuencias en determinadas condiciones. No son una promesa de inmunidad universal.

La versión 04 también sustituye JSON por TLV y especifica reglas de análisis y errores. Esas decisiones merecen examen por sí mismas, pero no deben disfrazarse como prueba de un incidente de seguridad. La noticia independiente es que los autores han retirado una afirmación de clave que el propio extremo TLS podía satisfacer. Un contador de «token válido» no debería convertirse, por vocabulario, en un certificado de todas las demás garantías.

Fuentes