Extensible Authentication Protocol (EAP) Using Privacy Pass Token

Extensible Authentication Protocol (EAP) Using Privacy Pass Token Apple Inc.

paresh_sawant@apple.com

Cisco Systems

bbrinckm@cisco.com

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 the 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. EAP-PPT must be performed only in a tunnel-based EAP method.

Introduction This document specifies Extensible Authentication Protocol (EAP) method, EAP-PPT, which uses Privacy Pass token for EAP peer authentication; see 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 . The tunnel-based EAP method MUST be a server authenticated TLS tunnel only. Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client . Privacy Pass tokens are issued to peer by token Issuers using an Issuance Protocol , and therefore, peer receives the token out of band of EAP-PPT. A client possessing such a token is able to prove that it was able to get it issued by a trusted Issuer, 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 when, and only when, they appear in all capitals, as shown here. Much of the terminology in this document is defined in . Additional terms are defined below:

NAI:: Network Access Identifier
TLV:: Type-Length-Value. A data object consisting of a type code, a length, and a value. EAP-PPT carries the contents of its messages as TLV objects, using the TLV format defined in ; see .
EAP-PPT peer:: This term is used for the entity acting as EAP peer. This term is identical to term Client defined in .
EAP-PPT server:: This term is used for the entity acting as EAP server. This term is identical to term Server defined in .
EAP server identity:: A name asserted for the EAP server by the certificate it presents during the first phase. specifies which certificate fields provide it.
Privacy Pass token:: Unlinkable authenticator that can be used to anonymously authorize a client . This is produced as an output of issuance protocol .
Token Challenge:: A single challenge presented by an EAP-PPT server, consisting of a TokenChallenge structure () and, optionally, the Issuer key and the ExtensionType values to which the token is to be bound. Carried in a Token-Challenge TLV ().
Token Redemption:: An action by which a peer presents a Privacy Pass token to a EAP-PPT server in EAP-PPT Protocol. See .
Identity provider:: An entity that is responsible for authentication of end-user devices with the purpose of granting them access to a network resource.

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 secure network access. EAP is one of the most preferred authentication mechanisms used for secure wireless LAN access using standard, wired LAN access using and Virtual Private Network (VPN) access. EAP is also used for secure network access for students and guests in academia, see . One goal of privacy is to protect individual's identity and personal information from eavesdroppers, intermediaries and recipients in the network communication. An individual's privacy may get compromised when network access is attempted using EAP as an authentication mechanism. The various privacy-specific threats are described in . Typical approaches for authorizing clients, such as through the use of a 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, identity providers, employers, or school/university administrators can track the individuals. The goal of this specification is to protect an individual from the 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 identity or pseudonym, 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. specifies the authentication scheme using Privacy Pass token over HTTP. mainly serves use cases where access to restricted services require anonymous client authorization. Since 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. EAP-PPT, performed inside a server-authenticated TLS tunnel offers anonymous network access to wired and wireless networks at those lower layers. Since EAP-PPT method provides unilateral authentication, it can be used together with responder authentication based on public key signatures in protocol. is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations. is widely used to implement remote access VPN service in public and enterprise environments, so EAP-PPT can be used to provide anonymous VPN services to clients. In summary, EAP-PPT provides a solution for networks that wish to offer anonymous network access to users and devices, protecting their privacy, while still being able to authorize them based on the possession of valid token that proves that a trusted attestation was performed based on the policies they defined for network access.

Architecture Model shows network architectural model for EAP-PPT.

EAP-PPT Architectural Model | Authen- |<---->| EAP |<---->| EAP- | | | | ticator | | Server | | PPT | | | | | | | | Server | +----------+ +----------+ +----------+ +----------+ ]]> The entities depicted in 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 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 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 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 , which requires the guidelines of to be followed. The TLS tunnel MUST be authenticated by an EAP server certificate. As required by , 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 . 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 . The second phase of the authentication begins after the TLS tunnel is established. Any EAP method that fulfills the requirements specified in 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 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 . 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 , Tunneled Transport Layer Security EAP (TTLS) , EAP Flexible Authentication via Secure Tunneling (EAP-FAST) and Tunnel Extensible Authentication Protocol (TEAP) . Optionally, the Privacy Pass token MAY also carry 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 .

Successful Authentication 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 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 (). 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 (). 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 .

EAP-PPT Successful Authentication | | | | | | EAP-Request/PPT-Challenge (challenges) | |<------------------------------------------------| | | | | | EAP-Response/PPT-Challenge (token) | |------------------------------------------------>| | | | +----------+ | | token | | | redeemed | | | | | +----------+ | EAP-Success | |<------------------------------------------------| | | | | ]]>

Failed Authentication 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 . The error information is encoded as TLV objects (). EAP-PPT peer responds to EAP-Request/PPT-Error with EAP-Response/PPT-Error without any data.

EAP-PPT Authentication Failure | | | | | | 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 , 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 ), 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 ), the AAA server MUST also include a RADIUS Session-Timeout attribute (see ) 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 Authentication Success with remediation | | | | | | 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 | |<------------------------------------------------| | | | | ]]>

Token Challenge Verification Failure 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 . 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 (). 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 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.

Token Challenge Verification Failure | | | | | | EAP-Request/PPT-Challenge | | (origin_info = a.ppt.example,b.ppt.example) | |<------------------------------------------------| | | +----------+ | | origin_ | | | info | | | mismatch | | +----------+ | | | | EAP-Response/PPT-Challenge | | (No-Suitable-Token) | |------------------------------------------------>| | | | | | EAP-Failure | |<------------------------------------------------| | | ]]>

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 . 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. 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 (). 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
() to get more tokens issued and cached at a time. EAP peer and server MUST send anonymous Network Access Identifiers (NAIs) () 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 , 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 . During TLS handshake in the first phase, EAP peer MUST send a Certificate message containing no certificates as described in , 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 () by shortening the TLS conversation using session resumption () 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. 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 , so session resumption MUST be used only on the same authenticator as for the original session. 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 (). A Protected Access Credential (PAC) in EAP-FAST () is a long-lived credential that would likewise allow a server to determine a peer's presence across session resumptions. and 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.

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 ; 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 (), 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 (), 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 . The resulting binding offers little protection, as noted for such inner methods in . 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 , 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 . EAP-PPT authorizes the peer; it does not key the link.

Channel Binding 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 . 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.

Message Format

Packet Format EAP-PPT Packet Format is shown below.

EAP-PPT Header 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 Data Zero or more TLV objects, encoded as defined in . The TLV objects carried by each message are specified in .

Subtypes EAP-PPT Subtypes

Subtype	Description
1	A PPT-Challenge request or PPT-Challenge response.
2	A PPT-Error request or PPT-Error response.
3	A PPT-Channel-Binding request or PPT-Channel-Binding response.

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 . 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 . 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 , so the set of TLV objects present is not a reliable indication of the message type.

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 , and is shown in . 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.

EAP-PPT TLV Format

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 . 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 ), and are not related to the TEAP TLV Type values enumerated in .
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 .

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.

TLV Types lists the TLV Types defined by this document. The Length column gives the permitted length of the Value field in octets. EAP-PPT TLV Types

Type	Name	Length
1	Token-Challenge	variable
2	Challenge	1-65535
3	Token-Key	1-65535
4	Extension-Types	2-65534
5	Token	1-65535
6	Extensions	1-65535
7	No-Suitable-Token	0
8	Error-Code	1
9	Error-Description	0-65535
10	Session-Timeout	4
11	Vendor-Specific-Error	5
12	Channel-Binding-Data	1-65535

The Value field of each TLV is encoded as described below.

Token-Challenge (1): A container carrying the TLVs that describe a single token challenge; see .
Challenge (2): A TokenChallenge structure as defined in , carried directly.
Token-Key (3): The Issuer public key for use with the issuance protocol indicated by the accompanying Challenge TLV, in the encoding specified by that issuance protocol, carried directly.
Extension-Types (4): A sequence of 2-octet ExtensionType values as defined in . The Length MUST be a non-zero multiple of 2.
Token (5): A Token structure as defined in , carried directly.
Extensions (6): An Extensions structure as defined in , carried directly.
No-Suitable-Token (7): Empty. Indicates that the peer could not use any of the Token-Challenges it received; see .
Error-Code (8): A 1-octet unsigned integer error code from the "EAP-PPT Error Codes" registry; see .
Error-Description (9): Human-readable UTF-8 text. Not NUL-terminated.
Session-Timeout (10): A 4-octet unsigned integer; time in seconds.
Vendor-Specific-Error (11): An enterprise-scoped error code; see .
Channel-Binding-Data (12): Channel binding data as defined in .

Token-Challenge TLV The Token-Challenge TLV is a container TLV. Its Value field consists of a sequence of TLV objects that together describe a single token challenge, as shown in .

Token-Challenge TLV The Value field contains:

exactly one Challenge TLV (Type 2) with the M bit set to 1;
at most one Token-Key TLV (Type 3) with the M bit set to 0. This TLV MAY be omitted in deployments where peers are able to retrieve the Issuer key using an out-of-band mechanism; and
at most one Extension-Types TLV (Type 4). This TLV is meaningful only if the Issuer, EAP-PPT peer and EAP-PPT server have an out-of-band agreement to bind the extension to the token. It carries the ExtensionType values that the EAP-PPT server is requesting the token to be bound to. The EAP-PPT server sets the M bit of the Extension-Types TLV according to its policy for tokens that are not bound to the requested ExtensionType values. A server that would reject such a token, and so would return error code 6 (), SHOULD set the M bit to 1, so that a peer unable to honor the request treats the Token-Challenge as unusable () rather than spending a token the server will reject. A server that would accept such a token, and so would return error code 7 or 8, SHOULD set the M bit to 0. The M bit of the Extension-Types TLV therefore expresses the EAP-PPT server's redemption policy, and not only whether the TLV Type has to be understood. When it is set to 1, a peer that cannot supply a token bound to the requested ExtensionType values MUST treat the Token-Challenge as unusable () whether or not it understands the Extension-Types TLV. This is a specialization, for this TLV only, of the general rule in .

A Token-Challenge TLV MUST NOT contain a nested Token-Challenge TLV. TLVs other than those listed above are handled as described in . The TokenChallenge structure carried in the Challenge TLV SHOULD have a non-empty origin_info field, and that field SHOULD contain a name of the EAP-PPT server. The name is a stable identity of the server. It MUST NOT be derived from a specific certificate, since a value such as a fingerprint or serial number would invalidate cached tokens whenever the certificate were renewed. A name in origin_info MUST NOT include a port, and the default port implied by has no meaning in EAP-PPT. A name in origin_info MUST NOT contain a wildcard, and MUST NOT be an IP address literal. An EAP-PPT server that populates origin_info MUST be provisioned with an EAP server certificate containing a subjectAltName extension with at least one dNSName, and at least one such dNSName MUST appear in the origin_info field it sends. An EAP-PPT server that sends an empty origin_info field issues cross-Origin tokens. The peer cannot then perform the verification in , and the deployment forgoes the protection described in and relies on certificate validation alone.

Vendor-Specific-Error TLV The Vendor-Specific-Error TLV carries an error code scoped to a single vendor, as described in . Its format is shown in .

Vendor-Specific-Error TLV

Enterprise Number: A 4-octet unsigned integer containing the vendor's IANA-assigned SMI Network Management Private Enterprise Number (PEN), obtained from the "Private Enterprise Numbers" registry .
Vendor Code: A 1-octet unsigned integer error code, interpreted within the private number space of the enterprise identified by the Enterprise Number field.

Parsing Requirements An EAP-PPT server parses TLV objects received from a peer that is, by design, unauthenticated at the time of parsing (see ). Implementations MUST therefore parse defensively. In particular:

An implementation determines the expected TLV composition from the Code and Subtype fields, as required by , before validating the TLV objects in the Data field.
An implementation MUST verify that the Length field of a TLV does not exceed the number of octets remaining in the enclosing Data field or container TLV before reading the Value field.
An implementation MUST verify that the Data field of a message, and the Value field of a container TLV, are each consumed exactly by a whole number of TLV objects. Trailing octets that do not form a complete TLV MUST cause the message to be treated as malformed.
An implementation MUST enforce the length constraints given for each TLV Type in . A TLV whose Length is not permitted for its Type MUST cause the message to be treated as malformed.
When this document specifies that a TLV Type occurs at most once in a message or container, an implementation MUST treat a second occurrence as malformed rather than selecting one of the occurrences.
This document defines container TLVs at a single level of nesting only. An implementation MUST treat the message as malformed if a container TLV appears inside another container TLV, and MUST NOT recurse without bound when parsing.
An implementation MUST validate that the contents of an Error-Description TLV form well-formed UTF-8 before displaying them, and MUST NOT assume the contents are NUL-terminated.

Handling of Unknown TLVs A recipient that encounters a TLV Type it does not understand proceeds as follows:

If the M bit is 0, the recipient MUST skip the TLV, using its Length field to locate the next TLV, and MUST continue processing the message. This allows TLVs to be added to EAP-PPT messages by future specifications without breaking existing implementations. A recipient MUST NOT reject a message solely because it contains a TLV with the M bit set to 0 that the recipient does not understand.
If the M bit is 1 and the TLV appears in the Value field of a Token-Challenge TLV, the recipient MUST treat that Token-Challenge as unusable, as described in . The message itself is not malformed, and the recipient MAY use any other Token-Challenge carried in it.
If the M bit is 1 and the TLV appears at the top level of the Data field, the recipient MUST treat the message as malformed.

A Token-Challenge TLV that is structurally invalid is a different case from one carrying an unrecognized mandatory TLV. A Token-Challenge TLV that does not contain exactly one Challenge TLV, or that violates any requirement in , indicates a defective sender rather than a version difference, and MUST cause the message to be treated as malformed. A message is also treated as malformed when it violates any requirement in or any composition requirement in . The action a recipient takes on receiving a malformed message depends on which message it is. An EAP-PPT server that receives a malformed EAP-Response/PPT-Challenge or a malformed EAP-Response/PPT-Channel-Binding MUST respond with an EAP-Request/PPT-Error carrying error code 9 () and MUST subsequently terminate the conversation with an EAP-Failure. Error code 9 reports that the message could not be parsed, and is distinct from error code 1, which reports that the token data carried in a well-formed message could not be validated. An EAP-PPT server that receives a malformed EAP-Response/PPT-Error MUST NOT send a further EAP-Request/PPT-Error, since doing so would solicit another acknowledgement that could itself be malformed. The server MUST instead terminate the conversation with an EAP-Failure, even where it would otherwise have sent an EAP-Success as described in . An EAP-PPT peer that receives a malformed EAP-Request/PPT-Challenge MUST respond with an EAP-Response/PPT-Challenge carrying a No-Suitable-Token TLV. An EAP-PPT peer that receives any other malformed EAP-PPT message MUST treat the authentication as failed. EAP-PPT defines no message with which a peer can report a protocol error to an EAP-PPT server, so a peer that cannot use a Token-Challenge for any reason, including a malformed one, signals this with a No-Suitable-Token TLV.

Processing a Token-Challenge Before selecting a token for a Token-Challenge, an EAP-PPT peer performs the checks in this section. A Token-Challenge that fails any of them is unusable (), and the peer MUST NOT redeem a token for it. The peer first determines the EAP server identities for the first phase. These are the subjectAltName dNSName values of the certificate presented during the TLS handshake. Where the first phase used session resumption and no certificate was presented, the peer uses the identities it determined during the full handshake for that association (). No other name in the certificate is an EAP server identity. The Common Name MUST NOT be used, nor any other attribute of the subject name (). A subjectAltName of any other type is not used, including iPAddress and an otherName of type NAIRealm ; a name in origin_info is a hostname (), and RFC 7585 defines the NAIRealm name form specifically to avoid conflating DNS names with NAI realm names. If the origin_info field of the TokenChallenge structure is non-empty, the peer MUST verify that at least one EAP server identity appears in the origin_info list. A certificate may assert more than one EAP server identity, and origin_info may name more than one Origin. The verification succeeds if the intersection of the two sets is not empty. Names are compared for case-insensitive equality, as in , and a wildcard in an identity matches at most one label. Comparison is over ASCII strings. An internationalized domain name appears in its A-label form on both sides, since origin_info is an ASCII string () and a subjectAltName dNSName is an IA5String (), so a peer performs no conversion between A-label and U-label forms. If origin_info is non-empty and no EAP server identity is available, because the certificate contained no subjectAltName dNSName, the peer cannot perform that verification and MUST treat the Token-Challenge as unusable. A peer MUST NOT skip the verification, and MUST NOT treat the Token-Challenge as though origin_info were empty. If origin_info is empty, no verification of the EAP-PPT server name is possible. The Token-Challenge is not unusable for that reason alone, but the peer obtains none of the protection described in . The peer MUST verify that it holds a token whose challenge_digest () is computed over the received TokenChallenge structure. A token obtained for any other TokenChallenge structure, including one differing only in origin_info or redemption_context, MUST NOT be redeemed.

Unusable Token Challenges An EAP-PPT peer MUST NOT select a token for a Token-Challenge that it cannot use. A Token-Challenge is unusable by a peer if any of the following hold:

the Token-Challenge contains a TLV that the peer does not understand with the M bit set to 1 (see );
the peer holds no token matching the TokenChallenge structure carried in the Challenge TLV; or
the Token-Challenge carries an Extension-Types TLV with the M bit set to 1, and the peer holds no token bound to the ExtensionType values that TLV carries.

A Token-Challenge carrying an Extension-Types TLV with the M bit set to 0 is not unusable merely because the peer holds no token bound to the requested ExtensionType values. In that case the peer MAY select a token that is not so bound, and the EAP-PPT server applies its redemption policy, reporting the outcome with error code 7 or 8 (). A peer that finds a Token-Challenge unusable MUST ignore that Token-Challenge and MAY use any other Token-Challenge carried in the same EAP-Request/PPT-Challenge message. If every Token-Challenge in the message is unusable, the peer MUST respond with an EAP-Response/PPT-Challenge carrying a No-Suitable-Token TLV (). Ignoring an unusable Token-Challenge avoids spending a token that the EAP-PPT server would reject. Tokens are single-use, and a peer may not be able to obtain replacements without first gaining network access (see ), so a peer that can determine in advance that a token would be rejected SHOULD NOT send one.

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

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 one or more 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 (). The Data field of this message contains one or more Token-Challenge TLVs (Type 1) with the M bit set to 1, each describing one token challenge as specified in . The order of the Token-Challenge TLVs is not significant. The structure of the message is summarized in ; a complete octet-level example is given in .

EAP-Request/PPT-Challenge contents The M bit of the Extension-Types TLV, shown as M=* above, is set by the EAP-PPT server according to its policy; see .

EAP-Response/PPT-Challenge The peer sends this message to the server in response to a valid EAP-Request/PPT-Challenge Message. This message is sent with subtype 1 (). The Data field of this message contains either:

exactly one Token TLV (Type 5) with the M bit set to 1, carrying a Privacy Pass token for one of the received challenges, and at most one Extensions TLV (Type 6) with the M bit set to 0; or
exactly one No-Suitable-Token TLV (Type 7) with the M bit set to 1, indicating that the peer could not use any of the Token-Challenges carried in the request ().

Sending a Token TLV indicates that the peer was able to look up a Privacy Pass token for one of the received challenges. The Token TLV and the No-Suitable-Token TLV are mutually exclusive. A message that carries both, or neither, MUST be treated as malformed (). An Extensions TLV MUST NOT be sent in a message that carries a No-Suitable-Token TLV. The peer MUST send a No-Suitable-Token TLV when every Token-Challenge in the request is unusable (). On receiving a No-Suitable-Token TLV, the server MUST send an EAP-Failure message to the peer.

EAP-Response/PPT-Challenge contents

EAP-Request/PPT-Error The server sends this message to the peer when token redemption fails, or when it needs to report the result of metadata validation to the peer (see ). The purpose of this message is to report the condition to the peer along with relevant information that may be useful to the peer. This message is sent with subtype 2 (). The Data field of this message contains:

exactly one of either an Error-Code TLV (Type 8) or a Vendor-Specific-Error TLV (Type 11), in both cases with the M bit set to 1;
at most one Error-Description TLV (Type 9) with the M bit set to 0; and
at most one Session-Timeout TLV (Type 10) with the M bit set to 0.

The Error-Code TLV carries a globally scoped error code from the "EAP-PPT Error Codes" registry (see ). The Vendor-Specific-Error TLV carries an error code scoped to the private number space of a single vendor (see ). A message MUST carry exactly one of the two; a message that carries both, or neither, MUST be treated as malformed (). The Error-Description TLV carries human-readable UTF-8 text providing additional information, used to assist the user of the client device in understanding the error. The Session-Timeout TLV carries the time in seconds after which the session is terminated by the authenticator.

EAP-Request/PPT-Error contents A complete octet-level example is given in .

Error Codes Error Codes

Code	Description
0	Reserved.
1	This code indicates a failure in validating the token data carried in a well-formed EAP-PPT message. This may occur due to the token structure being incorrectly formatted or encoded. A message that the EAP-PPT server could not parse at all is reported with code 9 instead.
2	This code indicates redemption failure. This is a fatal error, and the only way for the peer to recover from this failure is to retry the EAP-PPT authentication with a 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 indicates the server detected a double spend of the token. This is a fatal error, and the 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 spend the same token later.
6	This code indicates token redemption success with an unexpected extension parameter value. This is a fatal error, and the 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 a limited time. The limited time authorization is indicated by sending a Session-Timeout TLV along with the error code.
9	This code indicates that the EAP-PPT server could not parse the received EAP-PPT message, for example because it violates the TLV encoding rules in . This is a fatal error for the conversation. Whether the peer may use the same token again depends on whether that token has been spent; see .
10-191	Unassigned. Allocated on a Specification Required basis (see ).
192-255	Reserved.

The codes in are globally scoped values from the "EAP-PPT Error Codes" registry (see ) and are carried in the Error-Code TLV. A vendor that wishes to define its own error codes MUST NOT pick an arbitrary value from this space; instead, it indicates a vendor-specific error by sending a Vendor-Specific-Error TLV () in place of the Error-Code TLV, carrying its IANA-assigned Private Enterprise Number (PEN) and a code interpreted within that enterprise's private number space (see ).

Token Reuse and Double Spending An EAP-PPT server sends an EAP-Request/PPT-Channel-Binding message only after it has successfully redeemed the token carried in the preceding EAP-Response/PPT-Challenge message (). Receipt of that message therefore tells the EAP-PPT peer that its token was accepted, and the token is spent from that point in the conversation regardless of what happens afterwards. An EAP-PPT peer MUST NOT use a token in a subsequent authentication once it has received an EAP-Request/PPT-Channel-Binding message in the conversation in which that token was sent. This holds whatever error code the peer subsequently receives. An error code that permits a token to be used again is to be understood as applying only where the token has not been spent.

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 () and it does not carry data.

EAP-Request/PPT-Channel-Binding EAP-PPT server sends this message to the peer after a successful redemption of the token received in EAP-Response/PPT-Challenge message. The purpose of this message is to request channel binding information to the peer. This message is sent with subtype 3 () and it does not carry data.

EAP-Response/PPT-Channel-Binding The peer sends this message in response to an EAP-Request/ PPT-Channel-Binding Message. This message is sent with subtype 3 (). The Data field contains exactly one Channel-Binding-Data TLV (Type 12) with the M bit set to 1, whose Value is the channel-binding data defined in . An EAP-PPT server MAY send an EAP-Failure message if the channel-binding data is well formed but is not found valid or satisfactory, depending on the server side policy. A message that the EAP-PPT server cannot parse is handled as described in .

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 holds no valid token matching any of the received Token-Challenges, then every Token-Challenge in the message is unusable () and the EAP-PPT peer MUST respond with a No-Suitable-Token TLV 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 ExtensionType values requested by the EAP-PPT server in a Token-Challenge, that Token-Challenge is unusable (). The same applies if the peer does not support binding to extensions at all and the Extension-Types TLV was sent with the M bit set to 1. The peer MAY use any other Token-Challenge carried in the message. If every Token-Challenge in the message is unusable, the EAP-PPT peer MUST respond with a No-Suitable-Token TLV in the EAP-Response/PPT-Challenge message, and 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 an 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 received a malformed message If the EAP-PPT server cannot parse a received EAP-Response/PPT-Challenge or EAP-Response/PPT-Channel-Binding, for example because the message violates the TLV encoding rules in , the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 9 (see ). 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 . If the malformed message was an EAP-Response/PPT-Challenge, no token was redeemed and the EAP-PPT peer MAY use the same token in a subsequent authentication. If it was an EAP-Response/PPT-Channel-Binding, the token had already been spent before the channel binding exchange began, and the EAP-PPT peer MUST NOT use it again (). If the EAP-PPT server cannot parse a received EAP-Response/PPT-Error, it MUST NOT send a further EAP-Request/PPT-Error, and MUST instead terminate the conversation with an EAP Failure, as described in .

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 in an otherwise well-formed message, the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 1 (see ). 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 .

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 ). 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 . 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 ). 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 . 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 EAP-Response/PPT-Challenge, the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 4 (see ). 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 . 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 ). 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 . 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 ). 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 . 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 an 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 ). 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 .

EAP-PPT server redemption, unexpected extension value, conditional access If on receipt of an 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 ). The EAP-PPT server MUST send a Session-Timeout TLV 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 . 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. An example of such condition is when the peer needs to remediate its device to be compliant with the network access policy, or if the peer needs to get a new token issued from the Issuer with expected extension parameter value. The length of the session timer should in principle be as short as possible, but long enough for the device to reach compliance. For example for token issuance, if there is no user interaction required for issuance, a session timer of 1 minute should be sufficient. For remediation where user interaction is required, the session timeout could be more like 5 to 10 minutes.

Deployment Considerations EAP-PPT can be leveraged in a number of use cases and deployment models. This section covers generic deployment recommendations to ensure end-to-end privacy and unlinkability of tokens. This section also describes some specific expected deployment models in which EAP-PPT can be leveraged. Although this section covers deployment of Origin, Issuer and Attester as it relates to the EAP-PPT server, specifics on how to deploy Issuer and Attester are not described here but can be found in .

Recommendations for preserving privacy

Collocating other functions with the EAP-PPT Server As discussed in and in , it is recommended to use a deployment model that guarantees EAP peer-server, Issuer-EAP peer, and Attester-EAP server unlinkability. This is especially pertinent in public use cases. In private use cases a single entity could deploy all functions. It is recommended to collocate the phase 1 EAP server with the EAP-PPT server, as EAP server separation can introduce vulnerabilities as described in .

Protecting client identity Please refer to the section for deployment considerations that are required to protect the client identity.

Separating Issuance and Verification over time describes the interaction between Privacy Pass Issuance and Verification protocols. As described, in many cases, when a Client interacts with an Origin, a Client will obtain a token at the time of that interaction. In this case the time between Issuance and Verification is short enough to allow for correlation. In order to further reduce the probability of collusion between actors participating in Issuance and Verification and achieve Issuer-Client and Origin-Client unlinkability, Issuance and Verification can be separated over time. A client can request Issuance of one or more tokens and cache them in secure storage. This allows separation in time between Issuance and Verification of the token, so time-based correlation is not possible. When leveraging EAP-PPT to access network resources, it is possible that the client does not have a network interface available to perform Issuance over, so also for this reason caching tokens is preferred.

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

Recommendations for usage in private use cases It is recommended that the guidelines stipulated in 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 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.

Recommendations for usage in federated use cases (OpenRoaming) OpenRoaming, as described in , 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 . 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). 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 to use a publicly verifiable token type applies.

Security Considerations

PrivateToken authentication Scheme Security considerations discussed in are applicable to EAP-PPT.

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 , 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.

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.

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 (). 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 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 , removes the separation that the attack exploits within a provider's own infrastructure.
Channel binding () 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 (), 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.

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.

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.

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 , 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 , 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.

Security Claims This section provides the security claims required by . 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 . Key strength: N/A Dictionary attack prot.: N/A Fast reconnect: No Cryptographic binding: No. See . Session independence: N/A Fragmentation: No Key Hierarchy: No Channel binding: Yes

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 .

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".

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 ). 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 , are: EAP-PPT TLV Types Registration Procedures

Type	Registration Procedure
0	Reserved
1-16383	Specification Required

The initial contents of the registry are the values defined in of this document: Initial EAP-PPT TLV Types

Type	Name	Reference
1	Token-Challenge	RFC XXXX
2	Challenge	RFC XXXX
3	Token-Key	RFC XXXX
4	Extension-Types	RFC XXXX
5	Token	RFC XXXX
6	Extensions	RFC XXXX
7	No-Suitable-Token	RFC XXXX
8	Error-Code	RFC XXXX
9	Error-Description	RFC XXXX
10	Session-Timeout	RFC XXXX
11	Vendor-Specific-Error	RFC XXXX
12	Channel-Binding-Data	RFC XXXX

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 .

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 ). 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 , are: EAP-PPT Error Codes Registration Procedures

Code	Registration Procedure
0	Reserved
1-191	Specification Required
192-255	Reserved

The initial contents of the registry are the values defined in of this document: Initial EAP-PPT Error Codes

Code	Description	Reference
1	Failure in validating the token data.	RFC XXXX
2	Redemption failure.	RFC XXXX
3	Token redemption temporarily unavailable.	RFC XXXX
4	Double spend of the token detected.	RFC XXXX
5	Undefined failure.	RFC XXXX
6	Redemption success, unexpected extension (fatal).	RFC XXXX
7	Redemption success, unexpected extension (unconditional access).	RFC XXXX
8	Redemption success, unexpected extension (conditional access).	RFC XXXX
9	Malformed message.	RFC XXXX

[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 .

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 () 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 , 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 . 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.

References Normative References The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Extensible Authentication Protocol (EAP) This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK] The Network Access Identifier In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282. Tunnel Extensible Authentication Protocol (TEAP) Version 1 This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one. The Privacy Pass HTTP Authentication Scheme This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. Privacy Pass Issuance Protocols This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. Internet Key Exchange Protocol Version 2 (IKEv2) This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3 The Extensible Authentication Protocol-TLS (EAP-TLS) (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many other EAP Types also depend on TLS, such as EAP-Flexible Authentication via Secure Tunneling (EAP-FAST) (RFC 4851), EAP-Tunneled TLS (EAP-TTLS) (RFC 5281), the Tunnel Extensible Authentication Protocol (TEAP) (RFC 7170). It is possible that many vendor-specific EAP methods, such as the Protected Extensible Authentication Protocol (PEAP), depend on TLS as well. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also discussed. EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. The PrivateToken HTTP Authentication Scheme Extensions Parameter Google This document specifies new parameters for the "PrivateToken" HTTP authentication scheme, called extensions. The purpose of these extensions is to negotiate and carry public metadata for Privacy Pass protocols. Remote Authentication Dial In User Service (RADIUS) This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] The EAP-TLS Authentication Protocol The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK] Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK] Service Identity in TLS Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Protected Extensible Authentication Protocol (PEAP) Microsoft Corporation 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 IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control The Privacy Pass Architecture This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. The eduroam Architecture for Network Roaming This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience. Privacy Considerations for Internet Protocols This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes. This document is not an Internet Standards Track specification; it is published for informational purposes. Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community. The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides information for the Internet community. Privacy Pass Token Expiration Extension Google Cloudflare, Inc. This document describes an extension for Privacy Pass that allows tokens to encode expiration information. Batched Token Issuance Protocol Phoenix R&D Cloudflare Cloudflare Inc. This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. Registration Procedures for Private Enterprise Numbers (PENs) This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to modify a current PEN. It also gives a brief overview of PEN uses. Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS). WBA OpenRoaming Wireless Federation Wireless Broadband Alliance, Inc. Cisco Systems Intel Corporation Independent Cisco Systems IronWiFi This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architecture enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. This memo defines an Experimental Protocol for the Internet community. Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases To limit the privacy issues created by the association between a device, its traffic, its location, and its user in IEEE 802 networks, client vendors and client OS vendors have started implementing Media Access Control (MAC) address randomization. This technology is particularly important in Wi-Fi networks (defined in IEEE 802.11) due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the purpose of MAC address randomization. This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines some existing frameworks that maintain user privacy while preserving user quality of experience and network operation efficiency. Enterprise Number for Documentation Use This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community.

Test Vectors This appendix gives complete octet-level examples of EAP-PPT messages. Each example shows the full EAP-PPT packet, beginning with the Code field of the EAP header (). All values are hexadecimal. The Privacy Pass structures in these examples are syntactically well-formed but are not the output of a real issuance protocol run; they exercise the EAP-PPT framing only and cannot be verified cryptographically.

EAP-Request/PPT-Challenge A message carrying a single Token-Challenge TLV. The Token-Key TLV is omitted, as permitted by .

EAP-Request/PPT-Challenge

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.

EAP-Response/PPT-Challenge carrying a token

EAP-Response/PPT-Challenge Carrying No-Suitable-Token A message sent by a peer that holds no token matching any of the received challenges.

EAP-Response/PPT-Challenge carrying No-Suitable-Token

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.

EAP-Request/PPT-Error with a globally scoped code

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 .

EAP-Request/PPT-Error with a vendor-specific code

Notes on Referenced Documents This appendix records two observations about the documents this specification depends on. Neither of them changes any requirement stated in this document.

Key Exchange Mode Name in RFC 9190 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" (); 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 , since the surrounding text in that section discusses forward secrecy. Implementers should read the name in accordingly.

RFC 9427 and the Version of TLS 1.3 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. obsoletes RFC 8446 and is the current specification of TLS 1.3. This document is specified on the basis that the requirements of apply when the tunnel-based EAP method uses TLS 1.3 as specified in . Implementers comparing the two documents should note that the subsections of Section 4 of RFC 8446 were renumbered in , so a section number cited by may not identify the same subsection in .

Changes Since -03 Substantive changes:

The encoding of EAP-PPT message contents has been changed from JSON to Type-Length-Value (TLV) objects (), using the TLV format defined for TEAP in . All references to JSON (RFC 8259) have been removed from the document. Consequently:
- Privacy Pass structures (TokenChallenge, Token, Extensions) and Issuer public keys are now carried directly in TLV Value fields, rather than being base64url encoded and placed in JSON strings. The base64url encoding and its padding requirement have been removed, along with the reference to RFC 4648.
- The EAP-Response/PPT-Channel-Binding data is now carried in a Channel-Binding-Data TLV, so all EAP-PPT messages that carry data now use a single, uniform encoding.
- The "code", "description", "session-timeout" and "enterprise-number" JSON keys have been replaced by the Error-Code, Error-Description, Session-Timeout and Vendor-Specific-Error TLVs. Field widths that were previously stated as prose constraints are now structural: the error code is a 1-octet unsigned integer, the session timeout is a 4-octet unsigned integer, and the Private Enterprise Number is a 4-octet unsigned integer.
The mechanism for signaling that a peer holds no suitable token has changed. In -03 the peer sent an empty "token" string; it now sends an explicit No-Suitable-Token TLV, which is mutually exclusive with the Token TLV. This removes the overloading of an empty value as a protocol signal.
Vendor-specific error codes are now self-contained. In -03 the optional "enterprise-number" key reinterpreted the meaning of the "code" key. A Vendor-Specific-Error TLV now carries both the Private Enterprise Number and the vendor code, and is sent in place of, and is mutually exclusive with, the Error-Code TLV ().
The relationship between the Code and Subtype fields and the TLV objects expected in the Data field is now stated normatively (). A recipient determines the message type from Code and Subtype and validates TLV composition against it, and MUST NOT infer the message type from the TLV objects present. Without this rule a recipient could misclassify a message that carries no TLV objects, or one consisting only of TLV objects it skips under the M bit rule.
A new globally scoped error code 9 has been added, reporting that the EAP-PPT server could not parse the received message (). In -03 this condition was conflated with error code 1. The two are now distinguished, because they differ in what the peer may do next: code 1 means the token data in a well-formed message failed validation, whereas code 9 means no token was redeemed, so the peer MAY reuse the same token. The description of code 1 has been narrowed accordingly, and the Unassigned range in the registry now begins at 10.
The handling of a malformed message is now specified per message rather than as a single rule (). A server that receives a malformed EAP-Response/PPT-Error MUST NOT answer it with a further EAP-Request/PPT-Error, since that would solicit another acknowledgement which could itself be malformed; it terminates the conversation with an EAP-Failure instead, even where it would otherwise have sent an EAP-Success under .
New normative parsing requirements have been added (), covering length validation, complete consumption of the Data field, per-Type length constraints, rejection of repeated TLVs where at most one is permitted, and a single permitted level of container nesting.
Handling of unknown TLVs is specified via the M (mandatory) bit (), giving EAP-PPT a defined forward-compatibility rule that the JSON encoding did not state. An unrecognized TLV with the M bit set is scoped to its enclosing container: inside a Token-Challenge TLV it makes only that Token-Challenge unusable (), leaving the peer free to answer any other challenge in the message, whereas at the top level of the Data field it makes the message malformed. A structurally invalid Token-Challenge TLV remains a malformed message, since it indicates a defective sender rather than a version difference.
The M bit of the Extension-Types TLV is no longer fixed at 0. The EAP-PPT server now sets it according to whether it would reject a token that is not bound to the requested ExtensionType values (), so that the bit expresses the server's redemption policy: set to 1 it demands binding, and set to 0 it signals that the server will accept a token without it. A peer that cannot satisfy a demand for binding declines that Token-Challenge () instead of spending a single-use token the server would reject, while a lenient server remains able to accept such a token and report the outcome with error code 7 or 8. For this TLV the M bit therefore carries meaning for every peer, not only for one that does not understand the TLV Type.
The two Client Failure Scenarios have been reworded to say that a peer sends a No-Suitable-Token TLV when every Token-Challenge in the message is unusable, rather than when one of them is. The previous wording was ambiguous for multi-issuer challenge sets.
A new "EAP-PPT TLV Types" registry has been requested (), including entry fields, registration procedures, initial contents, and guidance for the Designated Expert.
A new Security Considerations subsection on message parsing has been added (), describing the pre-authorization exposure of the EAP-PPT server's parser and the handling of server-supplied description text.
A Test Vectors appendix has been added () with complete octet-level examples of each message.
A Notes on Referenced Documents appendix has been added, recording that names the resumption key exchange mode "psk_dh_ke" where TLS 1.3 defines "psk_dhe_ke", and that was written against RFC 8446 whose Section 4 subsections were renumbered in .
The "Key Material Generation" section has been removed and replaced by "Key Derivation and Cryptographic Binding" (). EAP-PPT no longer derives an MSK or an EMSK. In -03 the method derived 128 octets from the TLS exporter of the session established by the tunnel-based EAP method, using the label "EXPORTER_EAP_PPT_Key_Material" and a context of the EAP Type concatenated with the redeemed token. That derivation was removed for three reasons. First, a Privacy Pass token is a bearer credential verified either with the Issuer public key or, for a privately verifiable token type, with key material the EAP-PPT server shares with the Issuer rather than with the peer. In neither case does running EAP-PPT establish a secret shared between the peer and the server from which keys could be derived; EAP-GTC is keyless for the same reason. Second, the token contributed nothing to the context, since it is transmitted inside the tunnel and is therefore available to any party holding that tunnel. Third, and most importantly, a value derived from the tunnel can be computed by a party that terminated the tunnel, so reporting it as inner method keying material would have caused a tunnel-based EAP method to compute a Crypto-Binding TLV that appears to bind the inner method to the tunnel while providing no such assurance. Nothing consumes an EAP-PPT MSK. EAP-PPT is required to run inside a tunnel-based EAP method, so the keying material supplied to the authenticator is always that of the tunnel-based method. Accordingly the Security Claims now report "Key derivation: No", "Key strength: N/A" and "Cryptographic binding: No", and the references to RFC 5705 and to Section 7.10 of RFC 3748 have been dropped.
A new Security Considerations subsection, "Tunnel Authentication and Server Certificate Validation" (), has been added. It states the relay attack that cryptographic binding would ordinarily detect, explains that the attack requires the peer to accept the attacker's server certificate, and recommends that an EAP-PPT peer validate the EAP server certificate against network-specific trust anchors, check the server identity, and neither defer the decision to the user nor accept a certificate on first use. It also collects the measures that bound the consequences of a successful relay: collocation of the EAP and EAP-PPT servers, channel binding, short-lived tokens, and double spend detection.
A rule on token reuse has been added (). An EAP-PPT server sends an EAP-Request/PPT-Channel-Binding message only after successfully redeeming the token, so receipt of that message tells the peer its token was accepted and the token is spent from that point in the conversation. A peer MUST NOT use that token again whatever error code it subsequently receives, and error codes that permit reuse apply only where the token has not been spent. Error codes 3, 5 and 9 all permit reuse and none of them stated this condition.
The deployment recommendations now state which Privacy Pass token types suit which deployment model. Publicly verifiable types, which require only the Issuer public key to be shared, are RECOMMENDED for public use cases because they allow the Issuer and the EAP-PPT server to stay in separate trust domains (). Privately verifiable types require the EAP-PPT server to hold key material the Issuer keeps secret, and so suit private deployments where those entities are already within one trust domain. The consequences for OpenRoaming are stated in the federated use case discussion.
The peer's processing of a received Token-Challenge is now specified (). The peer verifies that an identity asserted in the EAP server certificate appears in the origin_info field of the TokenChallenge structure, and verifies that the token it redeems was obtained for the exact TokenChallenge structure received. Matching uses subjectAltName dNSName values; the Common Name MUST NOT be used (), and a subjectAltName otherName of type NAIRealm is not used, since a name in origin_info is a hostname and RFC 7585 defines that name form specifically to avoid conflating DNS names with NAI realm names. A name in origin_info carries no port, no wildcard and no IP address literal, and comparison is over ASCII strings, so an internationalized name appears in its A-label form on both sides and no conversion is performed (). An EAP-PPT server SHOULD populate origin_info, and one that does MUST have a subjectAltName dNSName appearing in it (). A peer that receives a non-empty origin_info field but finds no subjectAltName dNSName treats the Token-Challenge as unusable, and MUST NOT skip the verification or treat origin_info as though it were empty. Together these constrain the relay attack described in without requiring keying material, which -03 attempted to provide and could not. shows the resulting message flow.
is now a normative reference. It is the document that specifies how the tunnel-based EAP methods that can carry EAP-PPT (PEAP, EAP-TTLS, EAP-FAST and TEAP) are used with TLS 1.3, and it updates RFC 4851, RFC 5281 and RFC 7170. is also now referenced, since requires its guidelines to be followed.
The requirement on pre-shared keys in the Protocol Overview has been restated. In -03 it read "TLS-PSK cipher suites [RFC8446, Section 9.2] MUST NOT be used", which named a construct TLS 1.3 does not have, cited a section concerning mandatory-to-implement extensions, and forbade the pre-shared keys that TLS 1.3 session resumption depends on, contradicting the fast reconnect recommendation in . The requirement is now expressed in terms of , which permits pre-shared key authentication only for resumption, and the positive requirement that the tunnel be authenticated by an EAP server certificate is stated explicitly.
EAP-PPT now requires the psk_dhe_ke key exchange mode for resumption, so that a resumed TLS session retains forward secrecy, and does not permit the deployment-specific exception that allows. This is a new requirement in -04.
The session resumption discussion in now distinguishes the requirement in to support resumption from this document's restrictions on when a peer uses it. The restrictions themselves are unchanged: a full TLS handshake after every new association, and resumption only on the same authenticator.
now cites , under which a session ticket cannot resume authentication unless the inner tunnel authentication completed successfully. Since EAP-PPT is that inner authentication, a failed token redemption cannot produce a resumable ticket.
The discussion of Protected Access Credentials in has been updated to note that deprecates the use of a PAC for TEAP and EAP-FAST with TLS 1.3.

Editorial changes:

References to TEAP have been updated from RFC 7170 to , which obsoletes it, and references to TLS 1.3 have been updated from RFC 8446 to , which obsoletes it. Two section references were adjusted for the renumbering in those documents: the general TLV format is , and the Certificate message is . The channel binding discussion retains the numbering it had in RFC 7170 ().
The two TLVs describing a challenge have been named to match . The container carrying one complete challenge offer is the Token-Challenge TLV (Type 1), and the TLV carrying the serialized TokenChallenge structure is the Challenge TLV (Type 2), matching the "challenge" parameter of and the "challenge" key used in -03. Type numbers are unchanged.
A packet diagram has been added for the Token-Challenge TLV (), matching the diagrams given for the other TLVs defined by this document.
The Terminology entry for "Token Challenge" now defines the structure rather than describing an action, so that it agrees with the TLV of the same name.
The "Conventions and Definitions" section has been removed. It contained nothing but a second invocation of the BCP 14 boilerplate, which caused the key words paragraph to be emitted twice. The boilerplate in now uses the tagged form.
A definition of "EAP server identity" has been added to , for the name a certificate asserts for the EAP server of the first phase. The term is used in and .
A definition of "TLV" has been added to , and the acronym is no longer expanded again in the body text.
It is now stated explicitly that EAP-PPT reuses only the TEAP TLV framing, and that the EAP-PPT TLV Type space is independent of the TEAP TLV Type space ().
The reference to is now informative rather than normative, since the document is Informational and is cited only to identify the IANA "Private Enterprise Numbers" registry.
The citation for the TokenChallenge structure has been corrected from to . Section 2.2.1 defines the Token structure and remains cited for the Token TLV.
An anchor has been added to the Remediation section so that it can be cross-referenced.
Occurrences of "peer", "server" and "authenticator" in running prose have been lowercased, consistent with and and with the definitions in . Capitalized forms are retained in the architecture diagram, in the reference to the term "Server" defined in , in section headings, and in proper terms such as Network Access Server. The forms "EAP-Server" and "EAP-Peer", which appeared in a few places and nowhere else in the EAP literature, have been replaced by "EAP server" and "EAP-PPT peer".
The Privacy Pass roles Issuer, Attester and Origin are now capitalized consistently, as they are in . Eight occurrences were lowercase, two of them in a paragraph of the public use case discussion whose third sentence already capitalized "Issuer". That paragraph now also says "TokenChallenge structure", matching every other reference to the structure in this document, and states that the key material required is that of each Issuer named in a TokenChallenge structure, rather than of "the issuers specified in the TokenChallenge"; a single TokenChallenge names one Issuer.
A number of typographical and grammatical errors carried over from earlier versions have been corrected, and spellings have been made consistent.

Changes Since -02 Substantive changes:

Vendor-specific error codes are no longer allocated from a reserved range of the "code" key. The 81-100 "Vendor Specific Errors" range defined in -02 has been removed and replaced by the optional "enterprise-number" key (), which scopes a "code" value to the sending vendor's IANA-assigned Private Enterprise Number. A peer that does not recognize an enterprise-scoped code MUST treat the condition as fatal and MUST NOT reuse the token.
The globally scoped error code space has been redefined: 0 is Reserved, 1-191 is allocated on a Specification Required basis, and 192-255 is Reserved. In -02 the space was 1-100, of which 9-80 was Reserved and 81-100 was for vendor use.
The value of the "code" key MUST now be in the range 0-255. No bound was stated in -02.
The IANA Considerations section now fully specifies the requested "EAP-PPT Error Codes" registry, including the registry group, entry fields, registration procedures, initial contents, and guidance for the Designated Expert ().

Editorial changes:

Corrected a malformed cross-reference in the OpenRoaming deployment discussion, clarified that "session-timeout" is expressed in seconds, and fixed a number of typographical errors.