Summary

  • draft-ietf-emu-eap-ppt-04 removes the previous revision's 128-octet exporter-derived output and now says explicitly that EAP-PPT produces neither an MSK nor an EMSK.
  • A Privacy Pass token is a bearer credential sent inside the TLS tunnel. The tunnel terminator can see that token and calculate the same exporter value, so those bytes cannot prove that the token holder and tunnel endpoint are one party.

A cryptographic exporter did exactly what it was asked to do. It returned 128 octets. The mistake was not in the bytes. It was in the authority that a protocol might have assigned to them.

Revision 03 of Extensible Authentication Protocol (EAP) Using Privacy Pass Token derived those octets from the carrying TLS tunnel under the label EXPORTER_EAP_PPT_Key_Material. Its context included the EAP type and the redeemed token. An implementation could report the result as EAP-PPT keying material, divided into a Master Session Key and an Extended Master Session Key.

Revision 04, dated 30 September, deletes that construction. It says EAP-PPT produces no MSK or EMSK and must not report keying material to the tunnel method. The deletion is more important than a new cipher suite would have been. It removes a claim the protocol could not substantiate: that tunnel-derived bytes bound the inner token holder to the tunnel.

The earlier bytes had no exclusive contributor

EAP-PPT is an inner EAP method. A peer obtains a Privacy Pass token out of band from an issuer, enters a server-authenticated TLS tunnel supplied by another EAP method, and sends the token to an EAP-PPT server for redemption. The token may be publicly verifiable with an issuer public key or privately verifiable with material shared between issuer and server.

Neither form gives the peer and EAP-PPT server a new shared secret. The peer demonstrates possession by transmitting a bearer credential. The server validates that credential. In the public case, verification uses public-key material. In the private case, the relevant secret is shared between issuer and server, not between server and peer.

The outer TLS exporter is different. It belongs to the tunnel session. Every party that terminates that tunnel can compute its exporter output. Because the bearer token travels inside the same tunnel, the terminator can also see the token used in the exporter context. Adding the token to the context distinguishes one derivation from another; it does not add an input hidden from the terminator.

The result could be unique to a session and still fail the more important question: who contributed an exclusive inner secret? No one did. A value can be fresh, well labelled and 128 octets long without proving that the token holder is the same entity as the tunnel endpoint.

Outer TLS cannot prove the inner peer

That distinction becomes dangerous inside TEAP. TEAP can use a Crypto-Binding TLV to combine tunnel and inner-method key material. If EAP-PPT reports bytes derived only from the tunnel and a visible token, the resulting calculation can look like a binding of two independent proofs. It is not. The tunnel terminator already has every input.

Revision 04 calls out this failure directly. Reporting the old value could let a tunnel-based method calculate a Crypto-Binding TLV while providing no assurance that the inner method had been cryptographically bound to the tunnel. The visual shape of the protocol would suggest two contributors; the cryptographic reality would contain one.

The corrected boundary is therefore unusually clean. EAP-PPT can authorize a peer by redeeming a token. It does not key the link. Link keying material comes from the outer tunnel-based EAP method. An implementation that exposes an MSK field for EAP-PPT has not discovered an extra guarantee; it has recreated the removed ambiguity.

A keyless inner method changes the relay model

Without an inner secret, server authentication becomes the first line of defense against relay. If an attacker convinces a peer to accept the attacker's TLS tunnel, the attacker can relay the inner EAP-PPT exchange to a genuine service, observe the bearer token and redeem it for the attacker's own access.

The draft consequently requires strict, network-specific validation of the EAP server certificate. The peer should match the expected server identity, reject failures instead of asking a user to click through them, and avoid trust-on-first-use for this decision. The origin_info carried in the Privacy Pass challenge can constrain challenge substitution when it is populated and checked against that certificate identity. It does not manufacture inner keying material.

Server placement also matters. Collocating the EAP server and EAP-PPT server removes one separation that a relay could exploit within a provider. Splitting Phase 1 and Phase 2 servers is not recommended unless their relationship and inter-server channel are protected. This is an operational trust decision, not merely a topology preference.

Channel binding can expose a mismatch between the network the peer believes it joined and the authenticator the server sees. Short-lived tokens limit the period of loss. Double-spend detection may reveal that a token appeared in two paths. These are useful constraints and detectors. None turns the old exporter output into proof of token-holder continuity.

The token can be spent before the context verdict

Revision 04 adds a separate ordering rule that operators should not bury inside a generic authentication-success counter. After a token has been redeemed, the EAP-PPT server may send EAP-Request/PPT-Channel-Binding before EAP Success. It may omit the request when an earlier method already supplied suitable channel-binding information.

Receipt of that request tells the peer that the token was accepted and is now spent. The rule survives what happens next. A malformed response, an invalid channel-binding value, an EAP error or a later access failure does not make the token reusable. Retry semantics that apply before redemption no longer apply after this point.

That makes token spend a narrow receipt. It proves successful redemption. It does not prove that channel binding passed, that EAP Success followed, that the outer method installed link keys, that a RADIUS or NAS decision admitted the session, or that packets actually crossed the network.

Treating “spent” as “connected” would collapse at least six decisions into one event. Treating EAP Success as proof that the same entity held the token and terminated the tunnel would repeat the problem revision 04 just removed from the key schedule.

Revision 04 changes more than encoding

The new version replaces JSON message content with TEAP-style TLVs and carries Privacy Pass structures directly rather than wrapping them in base64url strings. It adds an explicit No-Suitable-Token TLV, defines length and duplicate handling, limits nesting, gives unknown TLVs an M-bit rule and adds octet-level test vectors.

Error code 9 separates a malformed request in which redemption did not occur from a well-formed token-validation failure. The distinction matters because reuse depends on whether the server consumed the credential. The draft also expands relay analysis and clarifies recommendations for public, private and federated token types.

These changes make the wire contract more precise. They do not prove an implementation, interoperability, performance or deployment. The document is an active EMU Working Group Internet-Draft intended for the Standards Track. Datatracker still records I-D Exists, with no responsible area director, shepherd or telechat. It is not an RFC.

What an operator must join

An auditable deployment needs separate records for the configured network and expected EAP server name; certificate, trust anchor and actual tunnel endpoint; Privacy Pass challenge and origin_info; token type, issuer key and challenge digest; redemption result and spend time; channel-binding source and verdict; EAP Success or Failure; outer-method link keys; RADIUS and NAS policy; and observed network access.

Those records should be correlated, not flattened. The tunnel certificate answers which server identity the peer accepted. The redemption event answers whether a token validated. Channel binding answers whether independently observed network context agreed. EAP Success marks a protocol outcome. The NAS decision and traffic observation show whether access was actually granted and usable.

The leadership lesson is not that specifications lack value. Revision 04 is valuable because it stops a specification from lending false authority to a convincing-looking output. Running operation must now preserve the joins the deleted 128 bytes never could.

Sources