Resumen

  • draft-ietf-emu-eap-ppt-04 elimina los 128 octetos que la revisión anterior derivaba del exportador TLS exterior y afirma que EAP-PPT no produce ni MSK ni EMSK.
  • El token Privacy Pass es una credencial al portador que viaja dentro del túnel. Su terminador ve el token y calcula el mismo exportador; esos bytes no prueban que terminador y portador sean la misma parte.

El exportador criptográfico hizo lo que se le pidió: devolvió 128 octetos. El error no estaba en el cálculo, sino en la autoridad que podía atribuirse al resultado.

La revisión 03 de Extensible Authentication Protocol (EAP) Using Privacy Pass Token derivaba ese valor del túnel TLS exterior con la etiqueta EXPORTER_EAP_PPT_Key_Material. El contexto contenía el tipo EAP y el token canjeado. Una implementación podía presentar la salida como MSK y EMSK aportadas por EAP-PPT.

La revisión 04, fechada el 30 de septiembre, borra esa construcción. EAP-PPT ya no genera MSK ni EMSK y no debe entregar material de clave al método de túnel. La supresión hace el diseño más honesto: una cadena puede tener aspecto de clave y seguir sin probar que la credencial interior pertenecía al extremo TLS.

La credencial al portador no aporta un secreto exclusivo

EAP-PPT funciona como método EAP interior. El par obtiene fuera de banda un token Privacy Pass de un emisor, entra en un túnel TLS con servidor autenticado que proporciona otro método EAP y entrega el token a un servidor EAP-PPT para canjearlo.

Los tokens verificables públicamente se comprueban con la clave pública del emisor. Los verificables de forma privada se validan con material compartido entre emisor y servidor EAP-PPT. Ninguno establece un secreto nuevo entre el par y ese servidor. El par demuestra posesión enviando una credencial transferible; el servidor determina si puede aceptarla.

El exportador TLS pertenece a la sesión exterior. Toda parte que termina el túnel puede calcular su salida. Además, el token circula dentro del mismo túnel, de modo que el terminador también conoce el token incluido en el contexto. Incorporarlo distingue una derivación de otra, pero no añade una entrada secreta para el terminador.

El resultado puede ser fresco, exclusivo de la sesión, estar bien etiquetado y medir 128 octetos. Aun así no responde a la pregunta esencial: ¿qué secreto sólo conocido por el par interior intervino? Ninguno. La longitud y la apariencia aleatoria no sustituyen esa aportación.

El TLS exterior no demuestra quién es el par interior

La diferencia resulta delicada dentro de TEAP. Su Crypto-Binding TLV puede combinar material del túnel con material de un método interior. Si lo que EAP-PPT declara como clave interior se calcula únicamente con el propio túnel y un token visible, el resultado parece unir dos pruebas independientes, pero el terminador ya posee todas las entradas.

La revisión 04 expone el problema: informar el valor antiguo permitiría construir un Crypto-Binding TLV sin ofrecer una verdadera unión criptográfica entre EAP-PPT y el túnel. El diagrama mostraría dos contribuyentes; la realidad criptográfica tendría uno solo.

El límite corregido es sencillo. EAP-PPT puede autorizar al par canjeando el token, pero no genera las claves del enlace. Éstas provienen del método EAP exterior. Si una consola sigue mostrando MSK o una clave tipo exporter para EAP-PPT, no ha descubierto una garantía adicional: ha restaurado la ambigüedad que el borrador retiró.

Un método interior sin clave cambia el riesgo de retransmisión

Sin unión criptográfica interior, validar el certificado del servidor es la primera defensa frente al relay. Si un atacante logra que el par acepte su túnel TLS, puede retransmitir el intercambio EAP-PPT a un servicio legítimo, observar el token al portador y canjearlo para obtener acceso propio.

Por ello el documento exige una validación estricta, específica de la red, del certificado del servidor EAP. El par debe cotejar la identidad esperada, rechazar los fallos en vez de delegarlos al usuario y no basarse en confianza al primer uso. Cuando origin_info se rellena y se compara con la identidad del certificado, limita la sustitución del challenge; no crea material interior.

La ubicación de servidores también forma parte del modelo. Alojar juntos el servidor EAP y el servidor EAP-PPT elimina una separación aprovechable dentro de un proveedor. Dividir servidores de Phase 1 y Phase 2 no se recomienda sin una relación explícita y un protocolo entre servidores protegido. No es sólo una decisión de despliegue: asigna confianza.

El channel binding puede detectar discrepancias entre la red que cree visitar el par y el authenticator que conoce el servidor. Los tokens de vida corta acotan la pérdida; la detección de doble gasto puede descubrir un relay a posteriori. Son controles útiles, pero no convierten la salida eliminada en prueba de continuidad del portador.

El token puede gastarse antes del veredicto de contexto

La revisión 04 añade otra frontera temporal. Tras canjear correctamente un token, el servidor EAP-PPT puede enviar EAP-Request/PPT-Channel-Binding antes de EAP Success. Puede omitir la petición si un método EAP anterior ya suministró información apropiada.

Al recibirla, el par sabe que el token fue aceptado y ya está gastado. Lo que ocurra después no cambia esa condición. Una respuesta mal formada, un valor de contexto inválido, un error EAP o un rechazo de acceso posterior no permiten reutilizarlo. Las reglas de reintento anteriores al canje dejan de aplicar.

«Token gastado» es, por tanto, un recibo limitado. Demuestra canje, no channel binding correcto, ni EAP Success, ni instalación de claves exteriores, ni autorización RADIUS/NAS, ni tráfico de red efectivo.

Contar gasto como conexión fusiona varias decisiones independientes. Interpretar EAP Success como prueba de que una misma entidad poseía el token y terminaba el túnel repetiría en la telemetría el exceso que la revisión 04 eliminó del calendario criptográfico.

La revisión 04 cambia más que la codificación

La nueva versión sustituye el cuerpo JSON por TLV al estilo TEAP y transporta directamente estructuras Privacy Pass, sin envolverlas en base64url. Incorpora un TLV No-Suitable-Token, reglas de longitud y duplicados, consumo completo de campos, un solo nivel de anidación, tratamiento M-bit de TLV desconocidos y vectores de prueba a nivel de octeto.

El código de error 9 separa un mensaje mal formado sin canje de un token bien formado que falla al validarse. La diferencia decide si la credencial puede volver a usarse. También amplía el análisis de relay y aclara recomendaciones para tokens públicos, privados y federados.

Más precisión en el cable no significa despliegue. Es un Internet-Draft activo del grupo EMU con objetivo Proposed Standard. Datatracker lo mantiene en I-D Exists, sin director de área responsable, shepherd ni telechat. No es un RFC; las fuentes congeladas no acreditan implementación, interoperabilidad, rendimiento o adopción.

Operar exige unir recibos distintos

Una operación auditable conserva por separado la red configurada y el nombre esperado del servidor EAP; certificado validado, ancla y extremo TLS real; challenge y origin_info; tipo de token, clave del emisor y resumen del challenge; resultado y hora del canje; origen y veredicto del channel binding; EAP Success o Failure; claves exteriores; decisión RADIUS/NAS; y acceso observado.

El certificado responde qué servidor aceptó el par. El canje responde si la credencial validó. El channel binding compara el contexto visto en ambos extremos. El resultado EAP cierra una fase de protocolo. Sólo la política NAS y el tráfico indican que el acceso fue aplicado y útil. Una casilla genérica de «autenticado» no contiene esas relaciones.

La lección no es restar valor a una especificación. La revisión 04 importa precisamente porque impide que una salida convincente reciba autoridad que el mecanismo no posee. La operación debe guardar las uniones que los 128 octetos nunca pudieron demostrar.

Fuentes