Extensible Authentication Protocol (EAP) Using Privacy Pass Token

5.1. Overview

A tunnel-based EAP method supports authentication in two phases after the initial EAP Identity request/response exchange. In the first phase, it uses a TLS [RFC9846] handshake to provide an authenticated key exchange and to establish a protected tunnel. The EAP peer and server that are configured to perform the peer authentication using EAP-PPT method, MUST establish the TLS tunnel without peer authentication. EAP server MUST NOT send CertificateRequest to the TLS client during the TLS handshake, when peer authentication is desired using EAP-PPT method.¶

The TLS tunnel MUST be established as specified in [RFC9427], which requires the guidelines of [RFC9190] to be followed. The TLS tunnel MUST be authenticated by an EAP server certificate. As required by Section 2.1.1 of [RFC9190], pre-shared key authentication MUST NOT be used except for resumption. Pre-shared keys established by session resumption MAY be used, subject to the restrictions in Section 5.6. The psk_dhe_ke key exchange mode MUST be used for resumption, so that a resumed session retains forward secrecy; EAP-PPT does not permit the deployment-specific exception allowed by Section 2.1.3 of [RFC9190].¶

The second phase of the authentication begins after the TLS tunnel is established. Any EAP method that fulfills the requirements specified in [RFC6678] is called tunnel-based EAP method.¶

A peer supporting EAP-PPT MUST NOT send its username or any other permanent identifiers in the first and subsequent EAP-Response/Identity messages. EAP-Response/Identity message MUST contain only an anonymous NAI as per Section 2.4 of [RFC7542] in order to route the authentication request to the right AAA system.¶

EAP-PPT authentication MUST be performed inside the server authenticated TLS tunnel established by the tunnel-based EAP method.¶

During the EAP-PPT authentication, the server challenges the peer to present a Privacy Pass token, and the peer responds with a Privacy Pass token. Upon a successful verification of the token, the redemption of the token is deemed successful. EAP-PPT encodes the challenges, responses, results and errors as TLV objects, using the TLV format defined in Section 6.3. The Privacy Pass structures carried by EAP-PPT are conveyed directly, without any additional text encoding. Encapsulation of EAP-PPT method can be supported by any tunnel- based EAP methods e.g. Protected EAP [PEAP], Tunneled Transport Layer Security EAP (TTLS) [RFC5281], EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851] and Tunnel Extensible Authentication Protocol (TEAP) [RFC9930].¶

Optionally, the Privacy Pass token MAY also carry extensions
([I-D.draft-ietf-privacypass-auth-scheme-extensions]) with additional metadata relevant to the EAP-PPT server. An example of an extension that could be useful in EAP-PPT is token expiration, since tokens may be issued with a limited lifetime for security reasons. An expiration extension is described in [I-D.draft-hendrickson-privacypass-expiration-extension].¶

5.2. Successful Authentication

Figure 2 shows an example of basic, successful authentication exchange in EAP-PPT. At the minimum, EAP-PPT uses two roundtrips to authenticate and authorize the peer. As in other EAP schemes, an identity request/response message pair is usually exchanged first. As specified in [RFC3748] the initial identity request is not required, and MAY be bypassed in cases where the EAP-PPT server can presume the identity.¶

After obtaining the identity, the EAP-PPT server constructs EAP-Request/PPT-Challenge message with a set of token Challenges and sends it to the EAP-PPT peer. EAP-Request/PPT-Challenge message encodes the set of token Challenges as TLV objects (Section 6.3).¶

On receiving EAP-Request/PPT-Challenge message, the EAP-PPT peer looks at each token Challenge and looks up the most suitable Privacy Pass token. If EAP-PPT peer successfully finds the Privacy Pass token, it constructs EAP-Response/PPT-Challenge message containing the Privacy Pass token, and sends it to the EAP-PPT server. EAP-Response/PPT-Challenge message encodes the response data as TLV objects (Section 6.3).¶

The EAP-PPT server verifies the received Privacy Pass token in the EAP-Response/PPT-Challenge message. After a successful token Redemption, the EAP-PPT server sends EAP-Success.¶

EAP-PPT server verifies the Privacy Pass token using a procedure called token Redemption Section 2.2 of [RFC9577].¶

+----------+                                     +----------+
|          |                                     |          |
| EAP-PPT  |                                     | EAP-PPT  |
|  Peer    |                                     |  Server  |
|          |                                     |          |
+----------+                                     +----------+
     |                                                 |
     |             EAP-Request/Identity                |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |
     |        EAP-Response/Identity (User's NAI)       |
     |------------------------------------------------>|
     |                                                 |
     |                                                 |
     |       EAP-Request/PPT-Challenge (challenges)    |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |
     |        EAP-Response/PPT-Challenge (token)       |
     |------------------------------------------------>|
     |                                                 |
     |                                            +----------+
     |                                            | token    |
     |                                            | redeemed |
     |                                            |          |
     |                                            +----------+
     |                 EAP-Success                     |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |

5.3. Failed Authentication

Figure 3 shows how EAP-PPT server rejects the peer when token redemption fails. EAP-PPT server sends EAP-Request/PPT-Error message containing the error information like error code and error description as described in Section 6.4.3.1. The error information is encoded as TLV objects (Section 6.3). EAP-PPT peer responds to EAP-Request/PPT-Error with EAP-Response/PPT-Error without any data.¶

+----------+                                     +----------+
|          |                                     |          |
| EAP-PPT  |                                     | EAP-PPT  |
|  Peer    |                                     |  Server  |
|          |                                     |          |
+----------+                                     +----------+
     |                                                 |
     |             EAP-Request/Identity                |
     |<-------------------------------------------------
     |                                                 |
     |                                                 |
     |        EAP-Response/Identity (User's NAI)       |
     |------------------------------------------------>|
     |                                                 |
     |                                                 |
     |       EAP-Request/PPT-Challenge (challenges)    |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |
     |        EAP-Response/PPT-Challenge (token)       |
     |------------------------------------------------>|
     |                                                 |
     |                                            +----------+
     |                                            | failed   |
     |                                            | to       |
     |                                            | redeem   |
     |                                            | token    |
     |                                            +----------+
     |         EAP-Request/PPT-Error (error)           |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |
     |             EAP-Response/PPT-Error              |
     |------------------------------------------------>|
     |                                                 |
     |                                                 |
     |                   EAP-Failure                   |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |

5.4. Remediation

An EAP-PPT server MAY successfully validate a token, but fail to validate metadata carried in an extension. The EAP-PPT server MAY require different or more recently generated metadata, for example. In this case the EAP-PPT server MAY reject, or conditionally accept an EAP-PPT Authentication.¶

As shown in Figure 4, after successful token redemption, the EAP-PPT server MAY respond with a PPT error message containing error information like an error code and error description (see Section 6.4.3.1), to inform the EAP-PPT peer of the metadata validation issue. In this case, the EAP-PPT server MAY respond with an EAP-Failure or EAP-Success message, depending on the metadata specific policies set on the EAP-PPT server side. Since the peer proves the authenticity of issuance of token by providing cryptographically correct token, the EAP-PPT server MAY decide to authorize the peer conditionally.¶

The EAP-PPT server MAY optionally also include a Session-Timeout TLV in the PPT-Error, informing the EAP-PPT peer how long the session will be permitted in order for the EAP-PPT peer to remediate and request a new token from its Issuer. If the Session-Timeout TLV is included in the PPT-Error (see Section 6.4.3.1), the AAA server MUST also include a RADIUS Session-Timeout attribute (see Section 5.27 of [RFC2865]) with the same value in the Access-Accept RADIUS message to the authenticator (e.g., Network Access Server or IKEv2 Responder)). The EAP-PPT peer responds to the EAP-Request/PPT-Error with EAP-Response/PPT-Error without any data. The EAP-PPT peer MAY use the allotted session time to fetch a new token by contacting its Attester. After getting a new token issued, the EAP-PPT peer may subsequently re-authenticate.¶

+----------+                                     +----------+
|          |                                     |          |
| EAP-PPT  |                                     | EAP-PPT  |
|  Peer    |                                     |  Server  |
|          |                                     |          |
+----------+                                     +----------+
     |                                                 |
     |             EAP-Request/Identity                |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |
     |        EAP-Response/Identity (User's NAI)       |
     |------------------------------------------------>|
     |                                                 |
     |                                                 |
     |       EAP-Request/PPT-Challenge (challenges)    |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |
     |        EAP-Response/PPT-Challenge (token)       |
     |------------------------------------------------>|
     |                                                 |
     |                                            +----------+
     |                                            | token    |
     |                                            | redeemed |
     |                                            | with     |
     |                                            | invalid  |
     |                                            | extension|
     |                                            | metadata |
     |                                            +----------+
     |         EAP-Request/PPT-Error (error)           |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |
     |             EAP-Response/PPT-Error              |
     |------------------------------------------------>|
     |                                                 |
     |                                                 |
     |                   EAP-Success                   |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |

5.5. Token Challenge Verification Failure

Figure 5 shows an EAP-PPT peer declining to redeem a token because no identity in the EAP server certificate appears in the origin_info field of the received TokenChallenge structure, as required by Section 6.3.6. The challenge names a.ppt.example and b.ppt.example, while the certificate presented during the first phase identifies not-ppt.example, so the tunnel was not terminated by an EAP-PPT server named in the challenge. The peer treats the Token-Challenge as unusable (Section 6.3.7). Where every Token-Challenge in the message is unusable, the peer responds with a No-Suitable-Token TLV and the EAP-PPT server terminates the conversation.¶

This condition arises when an attacker has terminated the tunnel, and also when the first phase and the EAP-PPT conversation legitimately terminate at different servers, which Section 9.5 advises against. A peer cannot distinguish the two. No token is sent, so none is spent. The same flow applies when the peer holds no token whose challenge_digest covers the received TokenChallenge structure.¶

EAP server identity        = not-ppt.example
TokenChallenge origin_info = a.ppt.example,b.ppt.example
not-ppt.example does not appear in the origin_info list

+----------+                                     +----------+
|          |                                     |          |
| EAP-PPT  |                                     | EAP-PPT  |
|  Peer    |                                     |  Server  |
|          |                                     |          |
+----------+                                     +----------+
     |                                                 |
     |              EAP-Request/Identity               |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |
     |       EAP-Response/Identity (User's NAI)        |
     |------------------------------------------------>|
     |                                                 |
     |                                                 |
     |            EAP-Request/PPT-Challenge            |
     |   (origin_info = a.ppt.example,b.ppt.example)   |
     |<------------------------------------------------|
     |                                                 |
+----------+                                           |
| origin_  |                                           |
| info     |                                           |
| mismatch |                                           |
+----------+                                           |
     |                                                 |
     |           EAP-Response/PPT-Challenge            |
     |               (No-Suitable-Token)               |
     |------------------------------------------------>|
     |                                                 |
     |                                                 |
     |                   EAP-Failure                   |
     |<------------------------------------------------|
     |                                                 |

5.6. Privacy

The fundamental building block of privacy in EAP-PPT is use of Privacy Pass token, which is unlinkable authenticator, for authorization of the peer. EAP-PPT peer selects an Issuer to get a token issued from, using Issuance Protocol [RFC9578]. The Issuer generates a token response based on the token request, which is returned to the Client (generally via the Attester). Upon receiving the token response, the EAP-PPT peer computes a token from the token challenge and token response. This token can be validated by anyone with the per-Issuer key but cannot be linked to the content of the token request or token response.¶

If the EAP-PPT peer has a token, it includes it in a response to a challenge from EAP-PPT server. This token SHOULD be sent only once in reaction to a challenge; peers SHOULD NOT send tokens more than once, even if they receive duplicate or redundant challenges.¶

The EAP-PPT server validates that the token was generated by the expected Issuer and has not already been redeemed for the corresponding token challenge. Mechanism to prevent double-spending of tokens is out of scope of EAP-PPT method.¶

Section 4 of [RFC9576] discusses deployment models in detail. It is RECOMMENDED to use a deployment model that guarantees EAP peer-server, Issuer-EAP peer, and Attester-EAP server unlinkability. Mechanisms for enforcing non-collusion are out of scope of EAP-PPT method.¶

EAP-PPT peer MAY opt for token Caching by getting multiple tokens issued from a single token challenge structure (Section 2.1.1 of [RFC9577]). This improves privacy by separating the time of token issuance from the time of token redemption. Optionally, the peer MAY use a variant of Privacy Pass Issuance
([I-D.draft-ietf-privacypass-batched-tokens]) to get more tokens issued and cached at a time.¶

EAP peer and server MUST send anonymous Network Access Identifiers (NAIs) (Section 2.4 of [RFC7542]) in the first and subsequent EAP- Response/Identity messages. EAP peer MUST NOT send its username (or any other permanent identifiers) in the Identity Response. Following [RFC7542], it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g., anonymous@realm) is allowed. Note that the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of [RFC7542].¶

During TLS handshake in the first phase, EAP peer MUST send a Certificate message containing no certificates as described in Section 4.5.1 of [RFC9846], if CertificateRequest message is received. Many client certificates contain an identity such as an email address, and therefore, this document forbids client authentication during first phase.¶

It is desired to support fast reconnect (Section 7.2.1 of [RFC3748]) by shortening the TLS conversation using session resumption (Section 2.1.2 of [RFC5216]) during the first phase. EAP peer presents an identifier that was issued previously by the server, to attempt the session resumption. When a peer attempts to resume a TLS session using such an identifier it allows the EAP server to detect peer's revisit to the network.¶

Section 4 of [RFC9427] requires all EAP servers and peers to support resumption for TLS-based EAP methods. That is a requirement to implement the capability, and it does not oblige a peer to use it. This document restricts when an EAP-PPT peer uses resumption, and those restrictions are compatible with the requirement to support it.¶

Use of session resumption MUST be limited to the current association to the network. The EAP peer MUST perform a full TLS handshake during the first phase after every new association to the network. For example, an EAP peer can continue to resume TLS sessions during the re-authentications as long as the client device is associated to the same access point of the secure wireless LAN [IEEE-802.11], so session resumption MUST be used only on the same authenticator as for the original session.¶

Section 3 of [RFC9427] requires that an EAP server not permit a session ticket to resume authentication unless the inner tunnel authentication completed successfully. Since EAP-PPT is that inner authentication, a conversation in which token redemption failed cannot yield a ticket that resumes successfully, and an EAP server that cannot determine the authentication state of a ticket MUST assume that inner authentication did not complete (Section 5.1 of [RFC9427]).¶

A Protected Access Credential (PAC) in EAP-FAST (Section 3.2.2 of [RFC4851]) is a long-lived credential that would likewise allow a server to determine a peer's presence across session resumptions. Section 2.2 of [RFC9427] and Section 2.3 of [RFC9427] deprecate the use of a PAC for TEAP and EAP-FAST with TLS 1.3, so this concern does not arise for tunnel-based EAP methods using TLS 1.3. A deployment that nonetheless uses a PAC needs to treat it as an identifier that is linkable across sessions.¶

5.7. Key Derivation and Cryptographic Binding

EAP-PPT does not derive keying material. It produces neither an MSK nor an EMSK, and an implementation MUST NOT report keying material for EAP-PPT to the tunnel-based EAP method that carries it.¶

A Privacy Pass token is a bearer credential. How an EAP-PPT server verifies one depends on the token type. A publicly verifiable type, such as Blind RSA (token type 0x0002), is verified using the Issuer public key. A privately verifiable type, such as VOPRF (token type 0x0001), is verified using key material that the EAP-PPT server shares with the Issuer [RFC9578]; that key material is shared between the Issuer and the EAP-PPT server, and not with the EAP-PPT peer. In neither case does verification involve a secret that the peer also holds, and in both cases the peer demonstrates possession of a token simply by transmitting it. Running EAP-PPT therefore establishes no secret shared between the peer and the EAP-PPT server, and the method has nothing of its own from which to derive keys. In this respect EAP-PPT resembles EAP-GTC (Section 5.6 of [RFC3748]), which likewise carries a credential that the peer transmits rather than computes with, and which likewise derives no keys.¶

Deriving keying material from the TLS session established by the tunnel-based EAP method would not change this. Any such value is a function of that TLS session alone, so any party holding the session can compute it. Reporting such a value as EAP-PPT keying material would assert a property that the method does not provide.¶

For the same reason, EAP-PPT does not contribute to cryptographic binding. Cryptographic binding demonstrates that a single entity acted as the peer for the tunnel and for the methods executed within it (Section 7.2.1 of [RFC3748]), and it depends on the inner method contributing a secret that a party which terminated the tunnel cannot compute. A tunnel-based EAP method carrying EAP-PPT computes its compound keys as it does for any inner method that derives no keys; for TEAP see Section 6.2.1 of [RFC9930]. The resulting binding offers little protection, as noted for such inner methods in Section 3.6.5 of [RFC9930]. Deployments needing assurance that the tunnel endpoint and the EAP-PPT peer are the same entity have to obtain it by other means; collocating the EAP server with the EAP-PPT server, as recommended in Section 9.5, removes the separation that cryptographic binding would otherwise be relied on to detect.¶

The keying material supplied to the authenticator is therefore that of the tunnel-based EAP method, derived as specified for that method with TLS 1.3 in [RFC9427]. EAP-PPT authorizes the peer; it does not key the link.¶

5.8. Channel Binding

[RFC6677] defines channel bindings for EAP which solve the "lying NAS" and the "lying provider" problems, using a process in which the EAP peer gives information about the characteristics of the service provided by the authenticator to the Authentication, Authorization, and Accounting (AAA) server protected within the EAP authentication method. This allows the server to verify the authenticator is providing information to the peer that is consistent with the information received from this authenticator as well as the information stored about this authenticator.¶

EAP-PPT server can optionally request channel binding information to the EAP- PPT peer after a successful redemption of the token sent in EAP-Response/PPT- Challenge message. EAP-PPT server uses EAP-Request/PPT-Channel-Binding message to request the channel binding information to the peer. EAP-PPT server MUST send EAP-Request/PPT-Channel-Binding message after a successful redemption of the token and before sending EAP-Success message. EAP-PPT peer MUST send channel binding information in EAP-Response/PPT-Channel-Binding message in response to EAP-Request/PPT-Channel-Binding message. EAP-PPT MUST send the channel-binding information as defined in Section 5.3 of [RFC6677].¶

EAP-Request/PPT-Channel-Binding message is optional, and therefore EAP-PPT server may skip it when the EAP server has already received the information through EAP methods executed before EAP-PPT.¶

6.1. Packet Format

EAP-PPT Packet Format is shown below.¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Subtype    |             Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code 1 for request, 2 for response.¶

Identifier The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed for each request packet and MUST be echoed in each response packet.¶

Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, Subtype, and Data fields.¶

Type 57 (EAP-PPT)¶

Subtype Message subtypes as defined in Table 1¶

Data Zero or more TLV objects, encoded as defined in Section 6.3. The TLV objects carried by each message are specified in Section 6.4.¶

6.2. Subtypes

The Code and Subtype fields together identify which EAP-PPT message a packet represents, and therefore which TLV objects are expected in the Data field. A recipient MUST determine the message type from the Code and Subtype fields, and MUST then validate the TLV objects carried in the Data field against the composition specified for that message in Section 6.4. A TLV object that is not specified for the indicated message is skipped if its M bit is set to 0. If its M bit is set to 1, it is handled as described in Section 6.3.5.¶

A recipient MUST NOT infer the message type from the TLV objects present in the Data field. Two of the messages defined by this document carry no TLV objects at all, and a message may legitimately consist only of TLV objects that the recipient skips under Section 6.3.5, so the set of TLV objects present is not a reliable indication of the message type.¶

6.3. TLV Format

EAP-PPT messages carry their contents as a sequence of TLV objects in the Data field of the EAP-PPT packet. The TLV format used by EAP-PPT is identical to the TLV format defined for TEAP in Section 4.2.1 of [RFC9930], and is shown in Figure 7. EAP-PPT reuses only the framing defined there. The EAP-PPT TLV Type space is independent of the TEAP TLV Type space, and a given numeric value does not denote the same TLV in both protocols.¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory bit (1 bit). When set to 1, a recipient that does not understand the TLV Type MUST reject the enclosing message or Token-Challenge, as specified in Section 6.3.5. When set to 0, a recipient that does not understand the TLV Type MUST skip the TLV and continue processing the remainder of the message.¶

R

Reserved (1 bit). MUST be set to 0 by the sender and MUST be ignored by the recipient.¶

TLV Type

A 14-bit unsigned integer in network byte order identifying the TLV. Values are allocated from the "EAP-PPT TLV Types" registry (see Section 10.2), and are not related to the TEAP TLV Type values enumerated in Section 4.2.1 of [RFC9930].¶

Length

A 16-bit unsigned integer in network byte order giving the length of the Value field in octets. The Length field does not include the four octets occupied by the M, R, TLV Type and Length fields themselves. A Length of 0 indicates that the TLV carries no Value.¶

Value

The value of the TLV. Its contents and permitted lengths are determined by the TLV Type, as specified in Section 6.3.1.¶

TLV objects are neither padded nor aligned to any boundary; a TLV begins at the octet immediately following the last octet of the preceding TLV. All multi-octet integer fields defined in this document are in network byte order.¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|        TLV Type = 1       |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Challenge TLV (Type 2)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Token-Key TLV (Type 3), optional               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Extension-Types TLV (Type 4), optional            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|       TLV Type = 11       |          Length = 5           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Enterprise Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Vendor Code  |
+-+-+-+-+-+-+-+-+

6.4. Messages

This section specifies the messages used in EAP-PPT and the TLV objects that each message carries.¶

Token-Challenge TLV      (M=1, Type=1)     [1..n]
  |
  +-- Challenge TLV       (M=1, Type=2)
  +-- Token-Key TLV       (M=0, Type=3)    [optional]
  +-- Extension-Types TLV (M=*, Type=4)    [optional]

Token TLV                (M=1, Type=5)
Extensions TLV           (M=0, Type=6)     [optional]

  -- or --

No-Suitable-Token TLV    (M=1, Type=7)

Error-Code TLV            (M=1, Type=8)
  -- or --
Vendor-Specific-Error TLV (M=1, Type=11)

Error-Description TLV     (M=0, Type=9)     [optional]
Session-Timeout TLV       (M=0, Type=10)    [optional]

7.1. Client Failure Scenarios

7.2. Server Failure Scenarios

7.3. Conditional Acceptance Scenarios

8.1. Recommendations for preserving privacy

8.2. Recommendations for usage in public use cases

In public use cases, a network service provider may be working with one or more identity providers that are authenticating end-user devices using privacy pass tokens. As described in Section 8.1.1 it is recommended for the EAP-PPT server to be implemented by an entity other than the Attester or Issuer, to avoid the perception of collusion. In a public deployment scenario, the EAP-PPT server is likely to be collocated with the network service provider, or could be a service that the network service provider consumes from a 3rd party service provider, other than the Attester or Issuer.¶

In order to verify a token, an EAP-PPT server requires key material for each Issuer named in a TokenChallenge structure that it sends. In a public use case, this information has to be shared between the Issuer and the EAP-PPT server. The mechanism by which the Issuer shares this information with the EAP-PPT server is out of scope of this document.¶

The nature of that key material depends on the token type. A publicly verifiable token type, such as Blind RSA (token type 0x0002), requires only the Issuer public key to be shared with the EAP-PPT server, which allows the Issuer and the EAP-PPT server to remain in separate trust domains as recommended in Section 8.1.1. A privately verifiable token type, such as VOPRF (token type 0x0001), requires the EAP-PPT server to hold key material that the Issuer keeps secret, placing the two in a single trust domain. Publicly verifiable token types are therefore RECOMMENDED for public use cases.¶

8.3. Recommendations for usage in private use cases

It is recommended that the guidelines stipulated in Section 8.2 are also followed for private deployments, however in use cases where the network service provider is also the Attester, collocation of entities may be unavoidable. When collocating entities, separating Issuance and Verification over time as described in Section 8.1.3 provides additional privacy protection, as it becomes harder for entities to collude.¶

Privately verifiable token types, such as VOPRF (token type 0x0001), are suited to these deployments. Verifying such a token requires the EAP-PPT server to hold key material that the Issuer keeps secret, so the Issuer, the Attester and the EAP-PPT server are necessarily within a single trust domain. Where that is already the case, as it typically is in an enterprise deployment, the token type imposes no separation that the deployment does not already have.¶

8.4. Recommendations for usage in federated use cases (OpenRoaming)

OpenRoaming, as described in [I-D.draft-tomas-openroaming], is an open federation of entities of different types, mainly targeted at providing public Wi-Fi access. OpenRoaming defines distinct roles in its federation architecture: Network Access Providers provide access to network resources, and Identity Providers authenticate users for those network access providers. Members of the federation are identified by private PKI, managed by the Wireless Broadband Alliance (WBA). The members use these certificates to mutually authenticate each other and secure RADIUS over TLS (RadSec) messages used to transport EAP conversations between Network Access Providers and Identity Providers. A Network Access Provider discovers the authoritative Identity Provider for a client by resolving the realm portion of the outer identity provided by the client as described in [RFC7585].¶

OpenRoaming comprises a privacy policy, and aims to protect end-user privacy, however as it uses RADIUS attributes and EAP, inherently, information about end-users could be shared between Identity Provider and Network Access Provider. Examples of RADIUS attributes that could expose user privacy are Calling-Station-Id (MAC address of the device), Chargeable-User-ID, NAS-ID (location). Section 8 of [I-D.draft-tomas-openroaming] describes the RADIUS attributes OpenRoaming supports. EAP-PPT can add additional privacy protection to a federated use case such as OpenRoaming by separating the Issuance from Verification, so the entity performing the Authentication is not able to willingly or unwillingly share private information.¶

Where an OpenRoaming IDP both issues and verifies a credential, with EAP-PPT these roles are separated. In order to implement EAP-PPT in OpenRoaming, the Attester/Issuer would have to have an agreement with the EAP-PPT server verifying or redeeming the token. Together they are the OpenRoaming IDP. Alternatively, new roles could be defined in the OpenRoaming federation to allow Attesters/Issuers to interoperate with EAP-PPT servers within the OpenRoaming federation.¶

The EAP-PPT server could be implemented by the Network Access Provider directly, or by an entity in the federation.¶

In OpenRoaming the choice of token type follows from how the roles are divided. Where the Attester, Issuer and EAP-PPT server together constitute a single OpenRoaming IDP, they are within one trust domain and either kind of token type may be used. Where new federation roles allow an Attester or Issuer to interoperate with an EAP-PPT server operated by a different federation member, those entities are in separate trust domains, and the recommendation in Section 8.2 to use a publicly verifiable token type applies.¶

9.1. PrivateToken authentication Scheme

Security considerations discussed in Section 5 of [RFC9577] are applicable to EAP-PPT.¶

9.2. Message Parsing

An EAP-PPT server parses the TLV objects carried in an EAP-Response/PPT-Challenge message before the token those objects carry has been redeemed, and therefore before the peer has been authorized. EAP-PPT peers are anonymous by design, and the tunnel established by the tunnel-based EAP method is server authenticated only. The TLV parser in an EAP-PPT server is consequently reachable by any party able to reach the network and complete tunnel establishment, and it constitutes pre-authorization attack surface. Implementations MUST follow the parsing requirements in Section 6.3.4, and SHOULD additionally impose an implementation-defined upper bound on the number of TLV objects accepted in a single message.¶

An EAP-PPT peer parses TLV objects received from an EAP-PPT server that it has authenticated during the TLS handshake of the first phase, so a peer's exposure is lower than a server's. A peer that does not strictly validate the EAP server certificate is, however, exposed to the same class of attack.¶

The Error-Description TLV carries text that originates from the EAP-PPT server and that may be displayed to a user. An implementation that displays this text MUST validate that it is well-formed UTF-8, and SHOULD take steps to prevent it from being used to spoof user interface elements or to mislead the user into taking an unsafe action.¶

9.3. Integrity Protection

Since EAP-PPT method is used for anonymous authentication of EAP peer, it is REQUIRED to execute it within a server authenticated TLS tunnel, provided by a tunnel-based EAP method. When EAP-PPT is used to authenticate IKEv2 initiator to the responder, it is REQUIRED to use it in conjunction with a public-key-signature- based authentication of the responder to the initiator, before initiating the EAP-PPT authentication.¶

9.4. Tunnel Authentication and Server Certificate Validation

EAP-PPT provides no keying material and therefore contributes nothing to the cryptographic binding of the inner method to the tunnel (Section 5.7). An EAP-PPT peer consequently depends on authentication of the tunnel itself for the assurance that it is redeeming a token to the intended EAP-PPT server.¶

An attacker that can induce an EAP-PPT peer to establish a tunnel-based EAP method with it can relay the EAP-PPT exchange to a genuine EAP-PPT server inside a tunnel of its own, obtain the peer's token, and redeem it for its own network access. Cryptographic binding is the mechanism tunnel-based EAP methods ordinarily use to detect this, and it is not available to EAP-PPT. Mounting the attack requires the peer to accept the attacker's server certificate, so validation of that certificate is the primary defence.¶

An EAP-PPT peer SHOULD therefore validate the EAP server certificate strictly. In particular, a peer SHOULD:¶

• validate the certificate against trust anchors configured for the network being joined, rather than against the trust anchors used for general purposes;¶

• verify that the server identity in the certificate matches the identity configured for that network; and¶

• reject a certificate that fails either check, rather than deferring the decision to the user or accepting the certificate on first use.¶

A peer that accepts an EAP server certificate on first use, or that permits a user to override a validation failure, weakens its principal defence against this attack, and SHOULD NOT redeem a token over the resulting tunnel.¶

Where the EAP-PPT server populates origin_info, the verification in Section 6.3.6 also constrains this attack. An attacker that forwards the server's challenge unchanged presents a certificate that does not match origin_info, and the peer declines to redeem. An attacker that substitutes a challenge naming itself obtains a token bound to that challenge, which the EAP-PPT server then rejects, since the token's challenge_digest does not cover the challenge the server issued. To succeed, the attacker needs a certificate that the peer accepts for a name the EAP-PPT server itself asserts, which is impersonation of that name rather than a configuration weakness. Because the peer compares origin_info against the certificate it was presented, it does not need prior knowledge of the EAP-PPT server's name.¶

An EAP-PPT peer that receives a non-empty origin_info field but has no EAP server identity available cannot tell whether the EAP-PPT server is misconfigured or whether an attacker is presenting a certificate that asserts no name. Both are treated identically, and an implementation is expected to make the condition visible to an operator.¶

The following measures limit the consequences of a successful relay without preventing one. Deployments concerned about this attack SHOULD apply them in addition to strict certificate validation.¶

• Collocating the EAP server with the EAP-PPT server, as recommended in Section 9.5, removes the separation that the attack exploits within a provider's own infrastructure.¶

• Channel binding (Section 5.8) allows an EAP-PPT server to detect inconsistency between the network a peer believes it has joined and the authenticator the server is communicating with.¶

• Issuing tokens with a limited lifetime, for example by means of the expiration extension ([I-D.draft-hendrickson-privacypass-expiration-extension]), bounds the period for which a captured token is useful.¶

• Double spend detection makes a relay visible after the fact, since the legitimate peer's own redemption of the token will fail. An EAP-PPT server SHOULD implement double spend detection where this attack is a concern.¶

Because a Privacy Pass token is a bearer credential, a peer that redeems one over a tunnel it has not properly authenticated has disclosed it. The token is single use, carries no identity, and is not subject to offline dictionary attack, so the loss is bounded by that token and the network access it authorizes. It cannot, however, be undone by the EAP-PPT exchange itself.¶

9.5. EAP Server implementation

Allowing the EAP Phase 1 conversation to be terminated at a different server than the EAP-Phase 2 conversation can introduce vulnerabilities if there is not a proper trust relationship and protection for the protocol between the two servers.¶

As EAP-PPT is an identity-free credential, it mitigates loss of identity protection scenarios better than EAP-methods carrying identity. Identity protection is ensured, even if the credential is exposed to an attacker. Offline dictionary attacks are also mitigated with EAP-PPT as the credential is a single-use cryptographically signed token.¶

Separation of Phase 1 and Phase 2 EAP server with EAP-PPT as the inner EAP method can still introduce vulnerabilities to on-path active attacks between these EAP Servers if there is not a proper trust relationship between the servers, or if the protocol between the servers is not properly secured. An attacker could intercept a token in the PPT-Challenge response, or alter an EAP-Success or EAP-Failure message. It is important to note however that due to the single-use identity-free nature of the credential, the longevity of the attack is limited.¶

Therefore, separation of the EAP server (Phase 1) from the EAP-PPT server (Phase 2) conversation is NOT RECOMMENDED.¶

9.6. Channel Binding

[RFC6677] defines channel bindings for EAP which solve the "lying NAS" and the "lying provider" problems, using a process in which the EAP peer gives information about the characteristics of the service provided by the authenticator to the Authentication, Authorization, and Accounting (AAA) server protected within the EAP authentication method. This allows the server to verify the authenticator is providing information to the peer that is consistent with the information received from this authenticator as well as the information stored about this authenticator.¶

When collocating the EAP and EAP-PPT servers, as recommended in Section 9.5, channel binding can be implemented by leveraging a Phase 1 EAP method that supports Channel binding as defined in [RFC6677]. It is therefore RECOMMENDED to leverage a Phase 1 EAP method that supports Channel binding with EAP-PPT, for example TEAP [RFC9930], as described in Section 3.11.4 of [RFC9930].¶

9.7. Token Redemption Server implementation

EAP-PPT server MAY be implemented to perform token Redemption flow with an external redemption service, configured with required keys for redemption. In such scenario, a malicious EAP peers may generate a lot of protocol requests to mount a denial-of-service attack on the service. The EAP-PPT server implementation SHOULD take this into account and SHOULD take steps to limit the requests it generates towards the redemption service.¶

9.8. Abuse

EAP-PPT provides anonymous network access to peers possessing valid Privacy Pass tokens. This anonymous access can potentially be abused. This is not a problem that is unique to EAP-PPT. Other EAP tunneled EAP methods or other methods that provide anonymous access, such as EAP-PSK [RFC4764], EAP-TTLS and EAP-TLS with anonymous certificates, also have similar abuse potential.¶

To counter such abuse, network operators may implement various abuse mitigation techniques, such as:¶

• Leverage the attestation: EAP-PPT relies on a token that is proof of an attestation. The attestation required for network access will rely on the policy of the network provider. As such the attestation policy can be designed to ensure that both the device and the user meet that policy before being issued a token. This can help mitigate abuse by ensuring that only authorized users and devices are able to obtain tokens. Further more, in case where abuse is detected, future attestation can be denied.¶

• Leverage a Layer 2 identifier: In case of a public network, it may not be possible to update future attestation based on abuse detection. In this case a session can be blocked based on the Layer 2 identifier of the device (for example the MAC address). As described in [RFC9797], there are various levels of trust a device may have in a network. Based on the trust level, the device may present a Layer 2 identifier that is stable over time, or a randomized one. In case of EAP Authentication, devices present a stable Layer 2 identifier that is stable across sessions within a certain timeframe. This layer 2 identifier is used for association, so the advantage of leveraging it for abuse mitigation is that access can be denied at association time, before EAP authentication is performed.¶

• Leverage network-level abuse mitigation techniques: Network operators may have various network-level abuse mitigation techniques in place, such as rate-limiting, traffic filtering, and monitoring of network traffic to detect and mitigate abusive behavior. These techniques can be applied to EAP-PPT authenticated sessions. With these techniques, mitigation does not happen by excluding the user or device, but happens by mitigating the abuse itself.¶

9.9. Security Claims

This section provides the security claims required by [RFC3748].¶

Auth. mechanism: Privacy Pass token¶

Ciphersuite negotiation: No¶

Mutual authentication: No¶

Integrity protection: NO. However, EAP-PPT method executed within a tunnel-based EAP method established TLS tunnel is integrity protected. The cleartext EAP-PPT messages outside the tunnel are not integrity protected.¶

Replay protection: NO. However, EAP-PPT method executed within a tunnel-based EAP method established TLS tunnel is replay protected. The cleartext EAP-PPT messages outside the tunnel are not replay protected.¶

Confidentiality: No. However, EAP-PPT method executed within a tunnel-based EAP method established TLS tunnel is encrypted.¶

Key derivation: No. See Section 5.7.¶

Key strength: N/A¶

Dictionary attack prot.: N/A¶

Fast reconnect: No¶

Cryptographic binding: No. See Section 5.7.¶

Session independence: N/A¶

Fragmentation: No¶

Key Hierarchy: No¶

Channel binding: Yes¶

10.1. EAP Method Type

An EAP Method Type number is requested for EAP-PPT in the "Method Types" registry of the "Extensible Authentication Protocol (EAP) Registry".¶

10.2. EAP-PPT TLV Types Registry

IANA is requested to create a new registry called "EAP-PPT TLV Types" within a new "EAP-PPT Parameters" registry group. This registry records the TLV Type values that may appear in the TLV Type field of an EAP-PPT TLV (see Section 6.3).¶

Each entry in this registry contains the following fields:¶

Type:

A non-negative integer in the range 0-16383.¶

Name:

A short name for the TLV.¶

Reference:

The document(s) defining the TLV.¶

The registration procedures for this registry, following the policies defined in [RFC8126], are:¶

The initial contents of the registry are the values defined in Table 2 of this document:¶

When evaluating a request in the Specification Required range, the Designated Expert should confirm that the requested TLV is meaningful across implementations from different vendors, that its function is not already covered by an existing TLV, that its Value field encoding and permitted lengths are unambiguously specified, and that a stable, publicly available specification defines its semantics. The Designated Expert should also confirm that the specification states whether the TLV is expected to be sent with the M bit set, and in which EAP-PPT messages it may appear. Vendor-private information MUST NOT be registered in this registry; vendor-specific error conditions are conveyed using the mechanism described in Section 10.4.¶

10.3. EAP-PPT Error Codes Registry

IANA is requested to create a new registry called "EAP-PPT Error Codes" within the new "EAP-PPT Parameters" registry group. This registry records the globally scoped error codes that may appear in the Error-Code TLV of an EAP-Request/PPT-Error message (see Section 6.4.3.1).¶

Each entry in this registry contains the following fields:¶

Code:

A non-negative integer.¶

Description:

A short, human-readable description of the error.¶

Reference:

The document(s) defining the code.¶

The registration procedures for this registry, following the ranges defined in [RFC8126], are:¶

The initial contents of the registry are the values defined in Section 6.4.3.1 of this document:¶

[RFC Editor: please replace "RFC XXXX" above with the RFC number assigned to this document.]¶

When evaluating a request in the Specification Required range, the Designated Expert should confirm that the requested code describes an error condition that is meaningful across implementations from different vendors, that it is not already covered by an existing code, and that a stable, publicly available specification defines its semantics. Vendor-private error conditions MUST NOT be registered in this registry; they are conveyed using the enterprise-specific mechanism described in Section 10.4.¶

10.4. Vendor-Specific (Enterprise) Error Codes

To allow a vendor to define and "self-issue" its own error codes without registering them with IANA, and without risking collisions with codes defined by other vendors, an EAP-Request/PPT-Error message MAY carry a Vendor-Specific-Error TLV (Section 6.3.3) in place of the Error-Code TLV. The Enterprise Number field of that TLV carries the vendor's SMI Network Management Private Enterprise Number (PEN) assigned from the IANA "Private Enterprise Numbers" registry [RFC9371], and the Vendor Code field carries an error code interpreted within the private number space of that enterprise rather than as a value from the "EAP-PPT Error Codes" registry defined in Section 10.¶

Such enterprise-scoped codes are administered solely by the owning enterprise and MUST NOT be registered with IANA. Because Private Enterprise Numbers are globally unique, the combination of Enterprise Number and Vendor Code is itself globally unique, so different vendors can define overlapping Vendor Code values without ambiguity.¶

This document creates no IANA registry for enterprise-scoped error codes; IANA is not asked to track them.¶

An EAP-PPT peer that receives an Enterprise Number it does not recognize, or an enterprise-scoped Vendor Code it does not understand, MUST treat the condition as a fatal error, MUST NOT reuse the token in a subsequent authentication, and MAY surface the contents of the Error-Description TLV to the user. A peer cannot determine whether an unrecognized enterprise-scoped code denotes a condition that permits reuse of the token, so it MUST assume that it does not.¶

11.1. Normative References

[I-D.draft-ietf-privacypass-auth-scheme-extensions]

Hendrickson, S. and C. A. Wood, "The PrivateToken HTTP Authentication Scheme Extensions Parameter", Work in Progress, Internet-Draft, draft-ietf-privacypass-auth-scheme-extensions-03, 13 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme-extensions-03>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2865]

Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/rfc/rfc2865>.

[RFC3748]

Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/rfc/rfc3748>.

[RFC5216]

Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <https://www.rfc-editor.org/rfc/rfc5216>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6677]

Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, <https://www.rfc-editor.org/rfc/rfc6677>.

[RFC7296]

Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/rfc/rfc7296>.

[RFC7542]

DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/rfc/rfc7542>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9190]

Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022, <https://www.rfc-editor.org/rfc/rfc9190>.

[RFC9427]

DeKok, A., "TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3", RFC 9427, DOI 10.17487/RFC9427, June 2023, <https://www.rfc-editor.org/rfc/rfc9427>.

[RFC9525]

Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, <https://www.rfc-editor.org/rfc/rfc9525>.

[RFC9577]

Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass HTTP Authentication Scheme", RFC 9577, DOI 10.17487/RFC9577, June 2024, <https://www.rfc-editor.org/rfc/rfc9577>.

[RFC9578]

Celi, S., Davidson, A., Valdez, S., and C. A. Wood, "Privacy Pass Issuance Protocols", RFC 9578, DOI 10.17487/RFC9578, June 2024, <https://www.rfc-editor.org/rfc/rfc9578>.

[RFC9846]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/rfc/rfc9846>.

[RFC9930]

DeKok, A., Ed., "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 9930, DOI 10.17487/RFC9930, February 2026, <https://www.rfc-editor.org/rfc/rfc9930>.

11.2. Informative References

[I-D.draft-hendrickson-privacypass-expiration-extension]

Hendrickson, S. and C. A. Wood, "Privacy Pass Token Expiration Extension", Work in Progress, Internet-Draft, draft-hendrickson-privacypass-expiration-extension-03, 24 January 2025, <https://datatracker.ietf.org/doc/html/draft-hendrickson-privacypass-expiration-extension-03>.

[I-D.draft-ietf-privacypass-batched-tokens]

Robert, R., Wood, C. A., and T. Meunier, "Batched Token Issuance Protocol", Work in Progress, Internet-Draft, draft-ietf-privacypass-batched-tokens-08, 4 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-batched-tokens-08>.

[I-D.draft-tomas-openroaming]

Tomas, B., Grayson, M., Canpolat, N., Cockrell, B., Gundavelli, S., and S. Adamski, "WBA OpenRoaming Wireless Federation", Work in Progress, Internet-Draft, draft-tomas-openroaming-08, 12 June 2026, <https://datatracker.ietf.org/doc/html/draft-tomas-openroaming-08>.

[IEEE-802.1X]

IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control", February 2020.

[IEEE-802.11]

IEEE, "IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", February 2021.

[PEAP]

Microsoft Corporation, "Protected Extensible Authentication Protocol (PEAP)", June 2021.

[RFC4764]

Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, <https://www.rfc-editor.org/rfc/rfc4764>.

[RFC4851]

Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, DOI 10.17487/RFC4851, May 2007, <https://www.rfc-editor.org/rfc/rfc4851>.

[RFC5281]

Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, DOI 10.17487/RFC5281, August 2008, <https://www.rfc-editor.org/rfc/rfc5281>.

[RFC5612]

Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, <https://www.rfc-editor.org/rfc/rfc5612>.

[RFC6678]

Hoeper, K., Hanna, S., Zhou, H., and J. Salowey, Ed., "Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method", RFC 6678, DOI 10.17487/RFC6678, July 2012, <https://www.rfc-editor.org/rfc/rfc6678>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC7585]

Winter, S. and M. McCauley, "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October 2015, <https://www.rfc-editor.org/rfc/rfc7585>.

[RFC7593]

Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Architecture for Network Roaming", RFC 7593, DOI 10.17487/RFC7593, September 2015, <https://www.rfc-editor.org/rfc/rfc7593>.

[RFC9371]

Baber, A. and P. Hoffman, "Registration Procedures for Private Enterprise Numbers (PENs)", RFC 9371, DOI 10.17487/RFC9371, March 2023, <https://www.rfc-editor.org/rfc/rfc9371>.

[RFC9576]

Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June 2024, <https://www.rfc-editor.org/rfc/rfc9576>.

[RFC9797]

Henry, J. and Y. Lee, "Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases", RFC 9797, DOI 10.17487/RFC9797, June 2025, <https://www.rfc-editor.org/rfc/rfc9797>.

A.1. EAP-Request/PPT-Challenge

A message carrying a single Token-Challenge TLV. The Token-Key TLV is omitted, as permitted by Section 6.3.2.¶

01 2a 00 39 39 01               EAP-PPT header
                                  Code       = 1 (Request)
                                  Identifier = 0x2a
                                  Length     = 57
                                  Type       = 57 (EAP-PPT)
                                  Subtype    = 1 (PPT-Challenge)
80 01 00 2f                     Token-Challenge TLV
                                  M=1, R=0, Type=1, Length=47
   80 02 00 23                  Challenge TLV
                                  M=1, R=0, Type=2, Length=35
      00 02                       token_type = 0x0002
      00 0e                       issuer_name length = 14
      69 73 73 75 65 72 2e 65     "issuer.e"
      78 61 6d 70 6c 65           "xample"
      00                          redemption_context length = 0
      00 0e                       origin_info length = 14
      6f 72 69 67 69 6e 2e 65     "origin.e"
      78 61 6d 70 6c 65           "xample"
   00 04 00 04                  Extension-Types TLV
                                  M=0, R=0, Type=4, Length=4
      00 01                       ExtensionType 1
      00 05                       ExtensionType 5

A.2. EAP-Response/PPT-Challenge Carrying a Token

A message carrying a Token TLV for token_type 0x0001, for which Nk is 48 octets. The nonce, challenge_digest, token_key_id and authenticator fields are filled with repeated octet values for readability.¶

02 2a 00 9c 39 01               EAP-PPT header
                                  Code       = 2 (Response)
                                  Identifier = 0x2a
                                  Length     = 156
                                  Type       = 57 (EAP-PPT)
                                  Subtype    = 1 (PPT-Challenge)
80 05 00 92                     Token TLV
                                  M=1, R=0, Type=5, Length=146
   00 01                          token_type = 0x0001
   01 01 ... 01                   nonce, 32 octets of 0x01
   02 02 ... 02                   challenge_digest, 32 octets of 0x02
   03 03 ... 03                   token_key_id, 32 octets of 0x03
   04 04 ... 04                   authenticator, 48 octets of 0x04

A.3. EAP-Response/PPT-Challenge Carrying No-Suitable-Token

A message sent by a peer that holds no token matching any of the received challenges.¶

02 2a 00 0a 39 01               EAP-PPT header
                                  Code       = 2 (Response)
                                  Identifier = 0x2a
                                  Length     = 10
                                  Type       = 57 (EAP-PPT)
                                  Subtype    = 1 (PPT-Challenge)
80 07 00 00                     No-Suitable-Token TLV
                                  M=1, R=0, Type=7, Length=0

A.4. EAP-Request/PPT-Error with a Globally Scoped Code

A message carrying error code 8 (redemption success, unexpected extension, conditional access) with a description and a session timeout of 300 seconds.¶

01 2b 00 24 39 02               EAP-PPT header
                                  Code       = 1 (Request)
                                  Identifier = 0x2b
                                  Length     = 36
                                  Type       = 57 (EAP-PPT)
                                  Subtype    = 2 (PPT-Error)
80 08 00 01                     Error-Code TLV
                                  M=1, R=0, Type=8, Length=1
   08                             code = 8
00 09 00 0d                     Error-Description TLV
                                  M=0, R=0, Type=9, Length=13
   74 6f 6b 65 6e 20 65 78        "token ex"
   70 69 72 65 64                 "pired"
00 0a 00 04                     Session-Timeout TLV
                                  M=0, R=0, Type=10, Length=4
   00 00 01 2c                    300 seconds

A.5. EAP-Request/PPT-Error with a Vendor-Specific Code

A message carrying an enterprise-scoped error code. Private Enterprise Number 32473 is the PEN reserved for use in documentation [RFC5612].¶

01 2c 00 0f 39 02               EAP-PPT header
                                  Code       = 1 (Request)
                                  Identifier = 0x2c
                                  Length     = 15
                                  Type       = 57 (EAP-PPT)
                                  Subtype    = 2 (PPT-Error)
80 0b 00 05                     Vendor-Specific-Error TLV
                                  M=1, R=0, Type=11, Length=5
   00 00 7e d9                    Enterprise Number = 32473
   01                             Vendor Code = 1

B.1. Key Exchange Mode Name in RFC 9190

Section 2.1.3 of [RFC9190] states a requirement on the pre-shared key exchange mode used for resumption, and gives the name of that mode as "psk_dh_ke". TLS 1.3 defines only two values for the psk_key_exchange_modes extension, "psk_ke" and "psk_dhe_ke" (Section 4.3.9 of [RFC9846]); no mode named "psk_dh_ke" exists.¶

This document uses the name "psk_dhe_ke". That is the mode which performs an ephemeral key agreement alongside the pre-shared key and so provides forward secrecy, and it is evidently the mode intended by Section 2.1.3 of [RFC9190], since the surrounding text in that section discusses forward secrecy. Implementers should read the name in [RFC9190] accordingly.¶

B.2. RFC 9427 and the Version of TLS 1.3

[RFC9427] specifies how the tunnel-based TLS EAP methods that can carry EAP-PPT are used with TLS 1.3, and was written against RFC 8446. [RFC9846] obsoletes RFC 8446 and is the current specification of TLS 1.3.¶

This document is specified on the basis that the requirements of [RFC9427] apply when the tunnel-based EAP method uses TLS 1.3 as specified in [RFC9846]. Implementers comparing the two documents should note that the subsections of Section 4 of RFC 8446 were renumbered in [RFC9846], so a section number cited by [RFC9427] may not identify the same subsection in [RFC9846].¶