Summary

  • The 30 September revision of an EMU working-group Internet-Draft says EAP-PPT derives neither an MSK nor an EMSK. The preceding version proposed both from an exporter of the surrounding TLS tunnel. The document remains an Internet-Draft in I-D Exists, not an RFC or evidence of deployment.
  • A Privacy Pass token can be redeemed to authorize the peer, but it supplies no secret shared between that peer and the EAP-PPT server. Re-labelling a value computed by the tunnel endpoint as an inner-method key would make cryptographic binding look stronger than it is.

The most consequential change in the latest EAP-PPT draft is an absence. In revision 03, the proposed Privacy Pass-based EAP method took 128 octets from the TLS exporter of the tunnel that carried it and divided them into a Master Session Key and an Extended Master Session Key. Revision 04 deletes that derivation. Its new section 5.7 states that EAP-PPT produces neither key and that an implementation must not report EAP-PPT keying material to the tunnel-based EAP method. This is a changed design claim in an active EMU working-group Internet-Draft, not a published standard or a finding about an installed network.

Why did the authors remove what looked like a security feature? The inner method presents a Privacy Pass token. A publicly verifiable token is checked with an issuer public key; a privately verifiable one is checked with material shared between issuer and EAP-PPT server. Neither route gives the peer and EAP-PPT server a fresh secret known only to them. The peer demonstrates possession by transmitting a bearer credential. An outer TLS endpoint, by contrast, already has the TLS session from which the old exporter value was calculated.

The old formula could therefore produce bytes without proving that the token holder and tunnel peer were independently tied together.

That is the evidence boundary. Successful token redemption says something about acceptance of a credential under the server's policy. A validated TLS tunnel says something about the authenticated server endpoint. The link key delivered to the authenticator comes from the tunnel-based EAP method. None of these facts, alone, proves that EAP-PPT itself contributed a secret to cryptographic binding. Revision 04 now records Key derivation: No and Cryptographic binding: No in its security claims. It separately records Channel binding: Yes; the latter checks information about the network and authenticator and should not be renamed into the former assurance.

The revision also makes the operational consequence explicit. Section 9.4 describes a relay in which an attacker induces a peer to form a tunnel with the attacker, forwards the inner EAP-PPT exchange to a real server, and spends the peer's token for the attacker's network access. The draft says that attack requires the peer to accept the attacker's certificate; strict certificate validation against trust anchors configured for the network and the expected server identity is the primary defence. It advises against accepting a certificate on first use or allowing a user to override a failed check.

Collocation of EAP and EAP-PPT servers, channel binding, short token lifetime and double-spend detection can constrain consequences, but they do not magically convert a bearer token into an inner key exchange.

Other changes in revision 04 are real: the message format moves from JSON to TLVs, and parsing and error handling become more explicit. They are not the basis for a claim that a specific implementation is broken. The narrower news is that the authors removed a key-derivation assertion because its apparent proof could be generated by the same tunnel endpoint whose identity it was meant to test. A protocol's security vocabulary is useful only when it identifies the actor that actually supplies each assurance.

Sources