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

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 .

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:

An action by which a EAP-PPT Server requests EAP-PPT peer to present Privacy Pass Token for one of the presented challenges.

Token Redemption:

An action by which a peer presents a Privacy Pass token to a EAP-PPT Server in EAP-PPT Protocol. See .

Identity provider:

An entity that is responsible for authentication of end-user devices with the purpose of granting them access to a network resource.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Motivation EAP is predominantly used for authentication of users and devices trying to join a network. Its security and extensibility capabilities makes it a popular choice in implementing 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. TLS-PSK cipher suites MUST NOT be used. The second phase of the authentication begins after the TLS tunnel is established. Any EAP method that fulfils 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 RFC 7542 Section 2.4 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 uses JavaScript Object Notation (JSON) to encode the challenges, responses, results and errors. Encapsulation of EAP-PPT method can be supported by any tunnel- based EAP methods e.g. Protected EAP , 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 in JSON format. 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 in JSON format. The EAP-PPT server verifies the received Privacy Pass token in the EAP-Response/PPT-Challenge message. After a successful token Redemption, the EAP-PPT server sends EAP-Success. EAP-PPT Server verifies the Privacy Pass token using a procedure called token Redemption .

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 in JSON format. 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 value in the PPT-Error, informing the EAP-PPT peer how long the session will be permitted in order for the EAP-Peer to remediate and request a new token from its issuer. If the session-timeout attribute is included in the PPT-Error (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 | |<------------------------------------------------| | | | | ]]>

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 mechanism () 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. Similarly, use of Protected Access Credential (PAC) in EAP-FAST method () can potentially help the server determine peer's presence across session resumptions. This document recommends use of session resumption to be limited to the current association to the network. The EAP peer MUST perform 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 same access point of the secure wireless LAN , so session resumption MUST be used only on the same Authenticator as for the original session.

Key Material Generation The keys generated by this protocol, MSK and EMSK, are each in 64 octets in length. The protocol uses TLS exporter interface to generate the key material. The output of the exporter is intended to be associated with the TLS session established in the first phase, a unique label string, and a context. Type is the value of the EAP Type field defined in , and it contributes to the context value. For EAP-PPT, the Type value is 0x39. Context value is constructed by concatenating Type value with Privacy Pass token value that was sent in EAP-Response/PPT-Challenge message. Key material MUST be generated by the EAP-PPT peer after receiving EAP Success from the EAP-PPT server. The MSK and EMSK are derived from the Key_Material as described in . TLS_Exporter function is defined in

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 Data in JSON format.

Subtypes EAP-PPT Subtypes

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

Messages This section specifies the messages used in EAP-PPT.

EAP-Request/PPT-Challenge The Server sends this message to the peer after successfully learning the identity of the peer. The purpose of this message is to present multiple token challenges to the peer and receive a Privacy Pass token for one of the challenges from the peer. This message is sent with subtype 1 () and data is encoded in JSON format as shown in below - Token Challenges

Key	Type	Description
challenges	array	Array of one or more objects. Each element is an object that contains keys that are part the challenge. This is a required parameter.

Token Challenge Keys

Key	Type	Description
challenge	string	A string that contains a base64url token challenge value, encoded per . This document follows the default padding behavior described in , so the base64url value MUST include padding. The token structure is defined in . This key is based on the challenge parameter defined in . This is a required parameter.
token-key	string	A string that contains a base64url-encoded public key for use with the issuance protocol indicated by the challenge key. This key is based on the token-key parameter defined in . This parameter MAY be omitted in deployments where peers are able to retrieve the Issuer key using an out-of-band mechanism.
extension-types	array	An array of ExtensionType that the EAP-PPT server is requesting the token to bind to. ExtensionType is defined in Section 3 of I-D.draft-ietf-privacypass-auth-scheme-extensions. This parameter is meaningful only if the Issuer, EAP-PPT peer and server have an out-of-band agreement to bind the extension to the token. This is an optional parameter.

EAP-Request/PPT-Challenge Message carries JSON key "challenges" which is a JSON array of JSON objects. Each element in "challenges" is a JSON object that contains two keys i.e. "challenge" and "token-key", and optionally an array of "extension-types" as well, as shown in . Example EAP-Request/PPT-Challenge Data -

EAP-Response/PPT-Challenge The peer sends this message to the server in response to a valid EAP-Request/PPT-Challenge Message. Sending this Message indicates that the peer was able to look up a Privacy Pass token for one of the received challenges. This message is sent with subtype 1 () and data is encoded in JSON format as shown in . Token Challenge Response Keys

Key	Type	Description
token	string	A string that contains base64url-encoded token structure value per . This is a required parameter.
extensions	string	A string that contains base64url-encoded extension structure (Section 3 of .draft-ietf-privacypass-auth-scheme-extensions). This is an optional parameter.

The peer MUST send empty token string when it fails to find a valid token for one of the received challenges. On receiving an empty token string in this message, the server MUST send EAP-Failure message to the peer. Example EAP-Response/PPT-Challenge Data -

EAP-Request/PPT-Error The server sends this message to the peer when token redemption fails. The purpose of this message is to report redemption failure to the peer along with relevant information that may be useful to the peer. This message is sent with subtype 2 () and data is encoded in JSON format as shown in . Error Keys

Key	Type	Description
code	number	An error code that describes the reason for the redemption failure. The value MUST be in the range 0-255. When the "enterprise-number" key is absent, this is a globally scoped value registered in the "EAP-PPT Error Codes" registry (see ). When the "enterprise-number" key is present, this value is interpreted within the private number space of that enterprise (see ). This key is required.
description	string	Human-readable UTF-8 text providing additional information, used to assist the user of the client device in understanding the error. This is an optional key.
session-timeout	number	Time in seconds after which the session is terminated by the authenticator. This is an optional key.
enterprise-number	number	The vendor's IANA-assigned SMI Network Management Private Enterprise Number (PEN), obtained from the "Private Enterprise Numbers" registry . When present, the "code" value is interpreted within this enterprise's private number space, allowing vendors to self-issue error codes without registration (see ). This is an optional key.

Example EAP-Request/PPT-Error Data -

Error Codes Error Codes

Code	Description
0	Reserved.
1	This code indicates a failure in validating the token data. This may occur due to incorrect formatting or encoding of the data.
2	This code indicates redemption failure. This is a fatal error, and only way for the peer to recover from this failure is to retry the EAP-PPT authentication with new token.
3	This code means the EAP-PPT server is unable to perform the token redemption at the moment. This can be used by the client to retry spending the token later.
4	This code indicates the server detected a double spend of the token. This is a fatal error, and only way for the peer to recover from this failure is to retry the EAP-PPT authentication with a new token.
5	This code indicates undefined failure. The client MAY choose to spend the same token later.
6	This code indicates token redemption success with an unexpected extension parameter value. This is a fatal error, and only way for the peer to recover from this failure is to retry the EAP-PPT authentication with a new token, binding to expected extension parameter value.
7	This code indicates token redemption success with an unexpected extension parameter value. However, the server side policy makes this a non-fatal error, and therefore, the peer is authorized unconditionally.
8	This code indicates token Redemption success with an unexpected extension parameter value. However, the server side policy makes this a non-fatal error, and therefore the peer is authorized conditionally. The condition here is - an authorization for limited time. The limited time authorization is indicated by sending session-timeout parameter along with the error code.
9-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 "code" key when the "enterprise-number" key is absent. 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 including the "enterprise-number" key set to its IANA-assigned Private Enterprise Number (PEN) , in which case the "code" value is interpreted within that enterprise's private number space (see ).

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

EAP-Response/PPT-Channel-Binding The peer sends this message as an in response to a EAP-Request/ PPT-Channel-Binding Message. This message is sent with subtype 3 () and the data field contains channel-binding message as defined in . EAP-PPT server MAY send EAP-Failure message if the channel-binding data is not found valid or satisfactory, depending on the server side policy.

Error Handling

Client Failure Scenarios

EAP-PPT peer found no valid token for token challenge If on receipt of an EAP-Request/PPT-Challenge, the EAP-PPT peer cannot present a valid token matching for one of the received token challenges, then the EAP-PPT peer MUST respond with an empty token string in the EAP-Response/PPT-Challenge message. In this case, the EAP-PPT server MUST terminate the conversation by sending an EAP Failure packet.

EAP-PPT peer found no token with valid extension-types for token challenge If on receipt of an EAP-Request/PPT-Challenge, the EAP-PPT peer cannot present a valid token bound to the extension-type(s) requested by the EAP-PPT server for one of the received token challenges, then the EAP-PPT peer MUST respond with an empty token string in the EAP-Response/PPT-Challenge message. In this case, the EAP-PPT server MUST terminate the conversation by sending an EAP Failure packet.

Server Failure Scenarios

EAP-PPT server found no valid token challenge for user NAI If on receipt of a EAP Identity Response the EAP-PPT server does not have a token challenge for the user's NAI, the EAP-PPT server MUST terminate the conversation by responding with an EAP Failure packet.

EAP-PPT server is unable to validate token data If on receipt of an EAP-Response/PPT-Challenge, the EAP-PPT server is unable to validate the token data presented by the EAP-PPT peer (due to incorrect data, formatting or encoding), the EAP-PPT server MUST respond with an EAP-Request/PPT-Error with error code 1 (see ). 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 a EAP-Response/PPT-Challenge, the EAP-PPT server token redemption succeeds, but the EAP-PPT server finds an unexpected extension parameter value, The EAP-PPT server MAY deem this to be a recoverable error and allow the session to proceed unconditionally. In this case, the EAP-PPT server MAY respond with an EAP-Request/PPT-Error with error code 7 (see ). 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 a EAP-Response/PPT-Challenge, the EAP-PPT server token redemption succeeds, but the EAP-PPT server finds an unexpected extension parameter value, The EAP-PPT server MAY deem this to be a recoverable error and allow the session to proceed conditionally. In this case the EAP-PPT server MAY respond with an EAP-Request/PPT-Error with error code 8 (see ). The EAP-PPT server MUST send a session-timeout value in the response message. The EAP-PPT peer MUST subsequently acknowledge the error with an EAP-Response/PPT-Error message, after which the EAP-PPT server MUST respond with EAP Success as shown in . 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, EAP-PPT Server requires key material for the issuers specified in the TokenChallenge. In a public use case, this information will have to be shared between the issuer and EAP-PPT Server. The mechanism in which the Issuer shares this information with the EAP-PPT server is out of scope of this document.

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.

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.

Security Considerations

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

Integrity Protection Since EAP-PPT method is used for anonymous authentication of EAP peer, it is REQUIRED to execute it within a server authenticated TLS tunnel, provided by a 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.

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.

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. When collocating the EAP and EAP-PPT servers, as recommended in , channel binding can be implemented by leveraging a Phase 1 EAP method that supports Channel binding as defined in . It is therefore RECOMMENDED to leverage a Phase 1 EAP method that supports Channel binding with EAP-PPT, for example TEAP , as described in .

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: Yes Key strength: See Dictionary attack prot.: N/A Fast reconnect: No Cryptographic binding: N/A 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 Error Codes Registry IANA is requested to create a new registry called "EAP-PPT Error Codes" within a new "EAP-PPT Parameters" registry group. This registry records the globally scoped error codes that may appear in the "code" key of an EAP-Request/PPT-Error message (see ) when the "enterprise-number" key is absent. 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

[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 include the optional "enterprise-number" key (see ). The value of this key is the vendor's SMI Network Management Private Enterprise Number (PEN) assigned from the IANA "Private Enterprise Numbers" registry . When the "enterprise-number" key is present, the value of the "code" key is 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 "code" is itself globally unique, so different vendors can define overlapping "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 "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 "description" string 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 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 updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. 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. 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. 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] 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. 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. 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. 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. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. 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. 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. 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 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] A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] 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] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] 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. 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 Microsoft Corporation 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. 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. 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. 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. 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. 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. Google Cloudflare, Inc. This document describes an extension for Privacy Pass that allows tokens to encode expiration information. 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. 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. 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). 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. 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.

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.