Extensible Authentication Protocol (EAP) Using Privacy Pass Token
Internet-Draft draft-sawant-eap-ppt-00
Paresh Sawant
Apple Inc.
paresh_sawant@apple.com
Bart Brinckman
Cisco Systems
bbrinckm@cisco.com
03 July 2024
Internet-Draft
EAP
anonymous
authorization
Privacy Pass token
This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576.
Introduction
This document specifies Extensible Authentication Protocol (EAP) method, EAP-PPT, which uses Privacy Pass token for EAP peer authentication; [RFC9576] for more information about Privacy Pass. EAP-PPT MUST be used inside any tunnel-based EAP method that enables secure communication between a peer and a server by using Transport Layer Security (TLS) Protocol [RFC8446]. The tunnel-based EAP method MUST guarantee a server authenticated or optionally, mutually authenticated TLS tunnel.
Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client [RFC9576]. Privacy Pass tokens are issued to peer by token issuers using an Issuance Protocol [RFC9578]. A client possessing such a token is able to prove that it was able to get it issued, without allowing the relying party redeeming the client's token (the origin) to link it with the issuance flow.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Much of the terminology in this document is defined in [RFC3748].
Additional terms are defined below:
NAI:
Network Access Identifier [RFC7542]
EAP-PPT peer:
This term is used for the entity acting as EAP peer. This term is identical to term Client defined in Section 2 of [RFC9576].
EAP-PPT server:
This term is used for the entity acting as EAP server. This term is identical to term Server defined in Section 2 of [RFC9576].
Privacy Pass token:
Unlinkable authenticator that can be used to anonymously authorize a client [RFC9577]. This is produced as an output of issuance protocol [RFC9578].
Token Challenge:
An action by which a EAP-PPT Server requests EAP-PPT peer to present Privacy Pass Token for one of the presented challenges.
Token Redemption:
An action by which a peer presents a Privacy Pass token to a EAP-PPT Server in EAP-PPT Protocol. See Section 2.2 of [RFC9577].
Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Motivation
EAP is predominantly used for authentication of users and devices trying to join a network. Its security and extensibility capabilities makes it a popular choice in implementing a secure network access. EAP is one of the most preferred authentication mechanisims used for secure wireless access using IEEE 802.1X standard, wired access using IEEE 802.1X standard and Virtual Private Network (VPN) access. EAP is widely used for both public and enterprise network access. EAP is also used for secure network access for students and guests in academia, see [RFC7593].
Privacy means protecting individuals' identity and personal information from eavesdropers, intermediaries and recipients in the network communication. An individual's privacy may get compromized when network access is attempted using EAP as an authentication mechanism. The various privacy-specific threats are described in Section 5.2 of [RFC6973].
Typical approaches for authorizing clients, such as through the use of permanent identity or service provider generated pseudo identity, are not privacy-friendly since they allow servers to track clients across sessions and interactions. This means service providers or identity providers or employers or school/university administrators can track the individuals.
The goal of this specification is to protect an individual from the Section 5.2 of [RFC6973] in public and enterprise environments. EAP-PPT can be leveraged for authorization based on anonymous-credential authentication mechanisms. EAP-PPT takes a different approach: instead of carrying linkable state carrying information to servers, such as permanent or pseudonyms, EAP peer presents Privacy Pass tokens that attest to this information. These tokens are anonymous in the sense that a given token cannot be linked to the protocol instance in which that token was initially issued.
[RFC9577] specifies the authentication scheme using Privacy Pass token over HTTP. [RFC9577] mainly serves use cases where access to restricted services require anonymous client authorization. Since [RFC9577] functions at the application layer of a networking stack, it justifies a need of a protocol that can offer the similar functionality for the lower layers. Since EAP was designed for use in network access authentication, where IP layer connectivity may not be available, EAP-PPT can be used for anonymous client authorization for wired and wireless network access. Since EAP-PPT method provides unilateral authentication, it qualifies to be used together with responder authentication based on public key signatures in [RFC7296] protocol. [RFC7296] is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations. [RFC7296] is widely used to implement remote access VPN service in public and enterprise environments.
Architecture Model
Figure 1 shows network architectural model for EAP-PPT.
EAP-PPT Architectural Model

Peer

Authen-

EAP

EAP-

ticator

Server

PPT

Server

+----------+      +----------+      +----------+      +----------+
|          |      |          |      |          |      |          |
|   Peer   |<---->|  Authen- |<---->|   EAP    |<---->|  EAP-    |
|          |      |  ticator |      |  Server  |      |  PPT     |
|          |      |          |      |          |      |  Server  |
+----------+      +----------+      +----------+      +----------+

The entities depicted in Figure 1 are logical entities and may or may not correspond to separate network components. For example, the EAP Server and EAP-PPT Server might be a single entity; the authenticator and EAP Server might be a single entity; or the functions of the authenticator, EAP Server, and EAP-PPT Server might be combined into a single physical device. For example, typical IEEE 802.11 deployments place the authenticator in an access point (AP) while a RADIUS Server may provide the Tunneled EAP Method and EAP-PPT method Server components. The above diagram illustrates the division of labor among entities in a logical manner and shows how a distributed system might be constructed; however, actual systems might be organized differently.
Protocol Overview
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 [RFC8446] handshake to provide an authenticated key exchange and to establish a protected tunnel. The TLS tunnel MUST be server authenticated or optionally, mutually authenticated. The second phase of the authentication begins after the TLS tunnel is established. Any EAP method that fulfils the requirements specified in [RFC6678] is called tunnel-based EAP method.
EAP-PPT authentication MUST be performed inside the a 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 uses JavaScript Object Notation (JSON) [RFC8259] to encode the challenges, responses, results and errors. 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) [RFC7170].
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.
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 in JSON [RFC8259] format.
On receiving EAP-Request/PPT-Challenge message, the EAP-PPT peer looks at the 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 send it to the EAP-PPT server. EAP-Response/PPT-Challenge message encodes the response data in JSON [RFC8259] format.
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 Successful Authentication

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

+----------+                                     +----------+
|          |                                     |          |
| 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                     |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |

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, error description etc. The error information is encoded in JSON [RFC8259] format. EAP-PPT peer responds to EAP-Request/PPT-Error with EAP-Response/PPT-Error without any data.
EAP-PPT Authentication Failure

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

+----------+                                     +----------+
|          |                                     |          |
| 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                   |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |

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, error description etc. 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 value in the PPT-Error, informing the EAP-PPT peer how long the session will be permitted in order for the EAP-Peer to remediate and request a new token from its issuer. If the session-timeout attribute is included in the PPT-Error then 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 and subsequently re-authenticate.
EAP-PPT Authentication Success with remediation

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

+----------+                                     +----------+
|          |                                     |          |
| 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                   |
     |<------------------------------------------------|
     |                                                 |
     |                                                 |

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 deployement 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 vaiant of Privacy Pass Issuance
([I-D.draft-ietf-privacypass-batched-tokens-01]) to get more tokens issued and cached at a time.
EAP-PPT peer and server MUST support anonymous Network Access Identifiers (NAIs) (Section 2.4 of [RFC7542]). EAP-PPT 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].
Message Format
Packet Format
EAP-PPT Packet Format is shown below.
EAP-PPT Header

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

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 Data in JSON [RFC8259] format.
Subtypes
EAP-PPT Subtypes
Subtype | Description
1 | A PPT-Challenge request or PPT-Challenge response.
2 | A PPT-Error request or PPT-Error response.
Messages
This section specifies the messages used in EAP-PPT.
EAP-Request/PPT-Challenge
The Server sends this message to the peer after successfully learning the identity of the peer. The purpose of this message is to present multiple token challenges to the peer and receive a Privacy Pass token for one of the challenges from the peer. This message is sent with subtype 1 (Table 1) and data is encoded in JSON [RFC8259] format as shown in Table 2 below -
Token Challenges
Key | Type | Description
challenges | array | Array of one or more objects. Each element is an object that contains keys that are part the challenge. This is a required parameter.
Token Challenge Keys
Key | Type | Description
challenge | string | A string that contains a base64url token challenge value, encoded per [RFC4648]. This document follows the default padding behavior described in Section 3.2 of [RFC4648], so the base64url value MUST include padding. The token structure is defined in Section 2.2.1 of [RFC9577]. This key is based on the challenge parameter defined in Section 2.1.2 of [RFC9577]. This is a required parameter.
token-key | string | AA string that contains a base64url-encoded public key for use with the issuance protocol indicated by the challenge key. This key is based on the token-key parameter defined in Section 2.1.2 of [RFC9577]. This parameter MAY be omitted in deployments where peers are able to retrieve the Issuer key using an out-of-band mechanism.
extension-types | array | An array of ExtensionType that the EAP-PPT server is requesting the token to bind to. ExtensionType is defined in Section 3 of I-D.draft-ietf-privacypass-auth-scheme-extensions. This parameter is meaningful only if the Issuer, EAP-PPT peer and server have an out-of-band agreement to bind the extension to the token. This is an optional parameter.
EAP-Request/PPT-Challenge Message carries JSON key "challenges" which is a JSON array of JSON objects. Each element in "challenges" is a JSON object that contains two keys i.e. "challenge" and "token-key", and optionally an array of "extension-types" as well, as shown in Table 3.
Example EAP-Request/PPT-Challenge Data -

                    {

"challenges":
                    [
                    {

"challenge":

"AAIADmlzc3Vlci5leGFtcGxlIIo-g6M9mAB

dLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhh

bXBsZQ==",

"token-key":

"MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWC

GSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgKi

AwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM_KsluUsuZ

KIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi

7pA1I-beWiJNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwy

B6vGvcte155T8mKMTknaHl1fORTtSbvm_bOuZl5uEI7kPRGGi

KvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE7

KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0

zq0mTCBz_kl0DAHwDhCRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo

1Kpur1hLQPK0C2xNLfiJaXwIDAQAB"
                    },
                    {

"challenge":

"AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mA

BdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXh

hbXBsZQ==",

"token-key":

"67H-0zgxA2HAjQx1dpaWcSluBemaF9eSbf

wopT-r1In6wPgryoYkmmaPOlv6s3TJ"

"extension-types":
                    [

1,5,6
                    ]
                    }
                    ]
                    }

{
    "challenges":
    [
        {
            "challenge": "AAIADmlzc3Vlci5leGFtcGxlIIo-g6M9mAB
            dLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXhh
            bXBsZQ==",
            "token-key": "MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWC
            GSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgKi
            AwIBMAOCAQ8AMIIBCgKCAQEAyxrta2qV9bHOATpM_KsluUsuZ
            KIwNOQlCn6rQ8DfOowSmTrxKxEZCNS0cb7DHUtsmtnN2pBhKi
            7pA1I-beWiJNawLwnlw3TQz-Adj1KcUAp4ovZ5CPpoK1orQwy
            B6vGvcte155T8mKMTknaHl1fORTtSbvm_bOuZl5uEI7kPRGGi
            KvN6qwz1cz91l6vkTTHHMttooYHGy75gfYwOUuBlX9mZbcWE7
            KC-h6-814ozfRex26noKLvYHikTFxROf_ifVWGXCbCWy7nqR0
            zq0mTCBz_kl0DAHwDhCRBgZpg9IeX4PwhuLoI8h5zUPO9wDSo
            1Kpur1hLQPK0C2xNLfiJaXwIDAQAB"
        },
        {
            "challenge": "AAEADmlzc3Vlci5leGFtcGxlIIo-g6M9mA
            BdLzC-9Bn6a_TNXGAF42sShbu0zNQPpLODAA5vcmlnaW4uZXh
            hbXBsZQ==",
            "token-key": "67H-0zgxA2HAjQx1dpaWcSluBemaF9eSbf
            wopT-r1In6wPgryoYkmmaPOlv6s3TJ"
            "extension-types":
            [
                1,5,6
            ]
        }
    ]
}

EAP-Response/PPT-Challenge
The peer sends this message to the server in response to a valid EAP-Request/PPT-Challenge Message. Sending this Message indicates that the peer was able to look up a Privacy Pass token for one of the received challenges. This message is sent with subtype 1 (Table 1) and data is encoded in JSON [RFC8259] format as shown in Table 4.
Token Challenge Response Keys
Key | Type | Description
token | string | A string that contains base64url-encoded token structure value per Section 2.2.1 of [RFC9577]. This is a required parameter.
extensions | string | A string that contains base64url-encoded extension structure (Section 3 of .draft-ietf-privacypass-auth-scheme-extensions). This is an optional parameter.
The peer MUST send empty token string when it fails to find a valid token for one of the received challenges. On receiving an empty token string in this message, the server MUST send EAP-Failure message to the peer.
Example EAP-Response/PPT-Challenge Data -

                    {

"token":

"AAEADmlzc4Vlci5leGFtcGxlIIo-g6M9mABdLzC-1Bn6a_TNX

GAF52sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsCB=="
                    }

{
    "token": "AAEADmlzc4Vlci5leGFtcGxlIIo-g6M9mABdLzC-1Bn6a_TNX
    GAF52sShbu0zNQPpLODAA5vcmlnaW4uZXhhbXBsCB=="
}

EAP-Request/PPT-Error
The server sends this message to the peer when token redemption fails. The purpose of this message is to report redemption failure to the peer along with relevant information that may be useful to the peer. This message is sent with subtype 2 (Table 1) and data is encoded in JSON [RFC8259] format as shown in Table 5.
Error Keys
Key | Type | Description
code | number | An error code that describes the reason for the redemption failure. The range is 1-100. This key is required.
description | string | Human-readable ASCII text providing additional information, used to assist the user of the client device in understanding the error. This is an optional key.
session-timeout | number | Time in second after which the session is terminated by the authenticator. This is an optional key.
Example EAP-Request/PPT-Error Data -

                    {

"code":

1,

"description":

"invalid

token

format"
                    }

{
    "code": 1,
    "description": "invalid token format"
}

Error Codes
Error Codes
Code | Description
1 | This code indicates a failure in validating the token data. This may occur due to incorrect formatting or encoding of the data.
2 | This code indicates redemption failure. This is a fatal error, and only way for the peer to recover from this failure is to retry the EAP-PPT authentication with new token.
3 | This code means the EAP-PPT server is unable to perform the token redemption at the moment. This can be used by the client to retry spending the token later.
4 | This code indiates the server detected a double spend of the token. This is a fatal error, and only way for the peer to recover from this failure is to retry the EAP-PPT authentication with a new token.
5 | This code indicates undefined failure. The client MAY choose to the spend the same oken later.
6 | This code indicates token redemption success with an unexpected extension parameter value. This is a fatal error, and only way for the peer to recover from this failure is to retry the EAP-PPT authentication with a new token, binding to expected extension parameter value.
7 | This code indicates token redemption success with an unexpected extension parameter value. However, the server side policy makes this a non-fatal error, and therefore, the peer is authorized unconditionally.
8 | This code indicates token Redemption success with an unexpected extension parameter value. However, the server side policy makes this a non-fatal error, and therefore the peer is authorized conditionally. The condition here is - an authorization for limited time. The limited time authorization is indicated by sending session-timeout parameter along with the error code.
9-80 | Reserved
81-100 | Vendor Specific Errors.
EAP-Response/PPT-Error
The peer sends this message as an acknowledgement to the server in response to a valid EAP-Request/PPT-Error Message. This message is sent with subtype 2 (Table 1) and it does not carry data.
Error Handling
Client Failure Scenarios
EAP-PPT peer found no valid token for token challenge
If on receipt of an EAP-Request/PPT-Challenge, the EAP-PPT peer cannot present a valid token matching for one of the received token challenges, then the EAP-PPT peer MUST respond with an empty token string in the EAP-Response/PPT-Challenge message. In this case, the EAP-PPT server MUST terminate the conversation by sending an EAP Failure packet.
EAP-PPT peer found no token with valid extension-types for token challenge
If on receipt of an EAP-Request/PPT-Challenge, the EAP-PPT peer cannot present a valid token bound to the extension-type(s) requested by the EAP-PPT server for one of the received token challenges, then the EAP-PPT peer MUST respond with an empty token string in the EAP-Response/PPT-Challenge message. In this case, the EAP-PPT server MUST terminate the conversation by sending an EAP Failure packet.
Server Failure Scenarios
EAP-PPT server found no valid token challenge for user NAI
If on receipt of a EAP Identity Response the EAP-PPT server does not have a token challenge for the user's NAI, the EAP-PPT server MUST terminate the conversation by responding with an EAP Failure packet.
EAP-PPT server is unable to validate token data
If on receipt of an EAP-Response/PPT-Challenge, the EAP-PPT server is unable to validate the token data presented by the EAP-PPT peer (due to incorrect data, formatting or encoding), the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 1 (see Section 7.3.3.1). The EAP-PPT peer MUST subsequently acknowledge the error with an EAP-Response/PPT-Error message, after which the EAP-PPT server MUST respond with EAP Failure as shown in Figure 3.
EAP-PPT server token redemption failure
If on receipt of an EAP-Response/PPT-Challenge, the EAP-PPT server token redemption fails, the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 2 (see Section 7.3.3.1). The EAP-PPT peer MUST subsequently acknowledge the error with an EAP-Response/PPT-Error, after which the EAP-PPT server MUST respond with EAP Failure as shown in Figure 3. The EAP-PPT peer MUST NOT use this token in subsequent authentication.
EAP-PPT server temporary failure
If the EAP-PPT server is (temporarily) unable to perform token redemption, and it receives an EAP-Response/PPT-Challenge, the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 3 (see Section 7.3.3.1). The EAP-PPT peer MUST subsequently acknowledge the the error with an EAP-Response/PPT-Error message, after which the EAP-PPT server MUST respond with EAP Failure as shown in Figure 3. The EAP-PPT peer MAY use this token in subsequent authentication.
EAP-PPT server detected double spend
The EAP-PPT server MAY implement double spend detection, to ensure a token is only used once. If the EAP-PPT server implementing double spend detection detects double spend of a token sent in an an EAP-Response/PPT-Challenge, the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 4 (see Section 7.3.3.1). The EAP-PPT peer MUST subsequently acknowledge the error with an EAP-Response/PPT-Error message, after which the EAP-PPT server MUST respond with EAP Failure as shown in Figure 3. The EAP-PPT peer MUST NOT use this token in subsequent authentication.
EAP-PPT server undefined failure
If the EAP-PPT server is experiencing an undefined failure, when receiving an EAP-Response/PPT-Challenge, the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 5 (see Section 7.3.3.1). The EAP-PPT peer MUST subsequently acknowledge the error with an EAP-Response/PPT-Error message, after which the EAP-PPT server MUST respond with EAP Failure as shown in Figure 3. The EAP-PPT peer MAY use this token in subsequent authentication.
EAP-PPT server token redemption success with unexpected extension value
If on receipt of an EAP-Response/PPT-Challenge, the EAP-PPT server finds an unexpected extension parameter value, the EAP-PPT server MAY deem this to be a fatal error. In this case the EAP-PPT server MAY respond with an EAP-Request/PPT-Error with error code 6 (see Section 7.3.3.1). The EAP-PPT peer MUST subsequently acknowledge the error with an EAP-Response/PPT-Error message, after which the EAP-PPT server MUST respond with EAP Failure as shown in Figure 3. The EAP-PPT peer MUST NOT use this token in subsequent authentication.
Conditional Acceptance Scenarios
EAP-PPT server redemption, unexpected extension value, unconditional access
If on receipt of a EAP-Response/PPT-Challenge, the EAP-PPT server token redemption succeeds, but the EAP-PPT server finds an unexpected extension parameter value, The EAP-PPT server MAY deem this to be a recoverable error and allow the session to proceed unconditionally. In this case, the EAP-PPT server MAY respond with an EAP-Request/PPT-Error with error code 7 (see Section 7.3.3.1). The EAP-PPT peer MUST subsequently acknowledge the error with an EAP-Response/PPT-Error message, after which the EAP-PPT server MUST respond with EAP Success as shown in Figure 2.
EAP-PPT server redemption, unexpected extension value, conditional access
If on receipt of a EAP-Response/PPT-Challenge, the EAP-PPT server token redemption succeeds, but the EAP-PPT server finds an unexpected extension parameter value, The EAP-PPT server MAY deem this to be a recoverable error and allow the session to proceed conditionally. In this case the EAP-PPT server MAY respond with an EAP-Request/PPT-Error with error code 8 (see Section 7.3.3.1). The EAP-PPT server MUST send a session-timeout value in the response message. The EAP-PPT peer MUST subsequently acknowledge the error with an EAP-Response/PPT-Error message, after which the EAP-PPT server MUST respond with EAP Success as shown in Figure 2. The EAP Server MUST include a session-timeout attribute in the RADIUS Access-Accept packet to the Authenticator, so it can terminate the session when the session-timeout condition is no longer met.
Security Considerations
PrivateToken authentication Scheme
Security considerations applicable discussed in Section 5 of [RFC9577] are applicable to EAP-PPT.
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 tunnnel-based EAP method. The TLS tunnel can be optionally mutually authenticated. 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.
EAP Server implementation
Separation of the EAP-Server (Phase 1) from the EAP-PPT Server (Phase 2) conversation is NOT RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a different server than the Phase 2 conversation can introduce vulnerabilities if there is not a proper trust relationship and protection for the protocol between the two servers. Some vulnerabilities include:
- Loss of identity protection
- Offline dictionary attacks
- Lack of policy enforcement
- on-path active attacks (as described in [RFC7029])
This is especially important since EAP-PPT does not perform key derivation and as such does not generate an Extended Master Session Key (EMSK) and allows for crypto binding, therefore it is RECOMMENDED to implement the Phase 1 EAP server together with the Phase 2 EAP-PPT server.
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.3, 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 [RFC7170], as described in Section 3.11.4 of [RFC7170].
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.
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
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Cryptographic binding: N/A
Session independence: N/A
Fragmentation: No
Key Hierarchy: No
Channel binding: No
IANA Considerations
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the EAP-PPT protocol, in accordance with BCP 26 [RFC8126].
The EAP Method Type number 57 has been requested for EAP-PPT.
This document also calls for a registry of EAP-PPT error codes described in Section 7.3.3.1.
References
Normative References
[RFC8446]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[RFC9578]

Privacy Pass Issuance Protocols
S. Celi
A. Davidson
S. Valdez
C. A. Wood
June 2024
RFC 9578
DOI 10.17487/RFC9578
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC3748]

Extensible Authentication Protocol (EAP)
B. Aboba
L. Blunk
J. Vollbrecht
J. Carlson
H. Levkowetz, Ed.
June 2004
RFC 3748
DOI 10.17487/RFC3748
[RFC7542]

The Network Access Identifier
A. DeKok
May 2015
RFC 7542
DOI 10.17487/RFC7542
[RFC9577]

The Privacy Pass HTTP Authentication Scheme
T. Pauly
S. Valdez
C. A. Wood
June 2024
RFC 9577
DOI 10.17487/RFC9577
[RFC7296]

Internet Key Exchange Protocol Version 2 (IKEv2)
C. Kaufman
P. Hoffman
Y. Nir
P. Eronen
T. Kivinen
October 2014
STD 79
RFC 7296
DOI 10.17487/RFC7296
[RFC8259]

The JavaScript Object Notation (JSON) Data Interchange Format
T. Bray, Ed.
December 2017
STD 90
RFC 8259
DOI 10.17487/RFC8259
[RFC7170]

Tunnel Extensible Authentication Protocol (TEAP) Version 1
H. Zhou
N. Cam-Winget
J. Salowey
S. Hanna
May 2014
RFC 7170
DOI 10.17487/RFC7170
[I-D.draft-ietf-privacypass-auth-scheme-extensions]

The PrivateToken HTTP Authentication Scheme Extensions Parameter
Scott Hendrickson
Google
Christopher A. Wood
Cloudflare, Inc.
1 April 2024
Internet-Draft draft-ietf-privacypass-auth-scheme-extensions-00
[RFC2865]

Remote Authentication Dial In User Service (RADIUS)
C. Rigney
S. Willens
A. Rubens
W. Simpson
June 2000
RFC 2865
DOI 10.17487/RFC2865
[RFC4648]

The Base16, Base32, and Base64 Data Encodings
S. Josefsson
October 2006
RFC 4648
DOI 10.17487/RFC4648
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
Informative References
[PEAP]

Protected Extensible Authentication Protocol (PEAP)
Microsoft Corporation
June 2021
[RFC9576]

The Privacy Pass Architecture
A. Davidson
J. Iyengar
C. A. Wood
June 2024
RFC 9576
DOI 10.17487/RFC9576
[RFC7593]

The eduroam Architecture for Network Roaming
K. Wierenga
S. Winter
T. Wolniewicz
September 2015
RFC 7593
DOI 10.17487/RFC7593
[RFC6973]

Privacy Considerations for Internet Protocols
A. Cooper
H. Tschofenig
B. Aboba
J. Peterson
J. Morris
M. Hansen
R. Smith
July 2013
RFC 6973
DOI 10.17487/RFC6973
[RFC6678]

Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method
K. Hoeper
S. Hanna
H. Zhou
J. Salowey, Ed.
July 2012
RFC 6678
DOI 10.17487/RFC6678
[RFC5281]

Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)
P. Funk
S. Blake-Wilson
August 2008
RFC 5281
DOI 10.17487/RFC5281
[RFC4851]

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)
N. Cam-Winget
D. McGrew
J. Salowey
H. Zhou
May 2007
RFC 4851
DOI 10.17487/RFC4851
[I-D.draft-ietf-privacypass-batched-tokens-01]

Batched Token Issuance Protocol
Raphael Robert
Phoenix R&D
Christopher A. Wood
Cloudflare
8 April 2024
Internet-Draft draft-ietf-privacypass-batched-tokens-01
[RFC7029]

Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding
S. Hartman
M. Wasserman
D. Zhang
October 2013
RFC 7029
DOI 10.17487/RFC7029
[RFC6677]

Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
S. Hartman, Ed.
T. Clancy
K. Hoeper
July 2012
RFC 6677
DOI 10.17487/RFC6677