]> Wireless Broadband Alliance, Inc.

5000 Executive Parkway, Suite 302 San Ramon 94583 US bruno@wballiance.com

Cisco Systems

10 New Square Park Feltham TW14 8HA UK mgrayson@cisco.com

Intel Corporation

2111 NE. 25th Ave Hillsboro 97124 US necati.canpolat@intel.com

Independent

San Antonio US bcbeti@outlook.com

Cisco Systems

170 West Tasman Drive San Jose 95134 US sgundave@cisco.com

IronWiFi

100 E Pine St, Ste 110 Orlando 32801 US seb@ironwifi.com

general Independent Submission Internet-Draft OpenRoaming Federation 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.

Introduction WBA OpenRoaming is a roaming federation service of Access Network Providers (ANPs) and Identity Providers (IDPs), enabling an automatic and secure Wi-Fi experience globally. WBA OpenRoaming creates the framework to seamlessly connect billions of users and things to millions of Wi-Fi networks.

WBA OpenRoaming recognizes the benefits that the likes of eduroam provides to the education and research community. WBA OpenRoaming defines a global federation that is targeted at serving all communities, while supporting both settlement-free use cases where "free" Wi-Fi is being offered to end-users in order to support some alternative value proposition, as well as traditional settled "paid" for Wi-Fi offered by some cellular providers. OpenRoaming is designed to deliver end-to-end security between a Network Access Server (NAS) deployed by an OpenRoaming Access Network Provider and an EAP Server deployed by an OpenRoaming Identity Provider. The security of the solution is based on mTLS using certificates issued under Wireless Broadband Alliance's Public Key Infrastructure .

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

Terminology Access Network Query Protocol (ANQP):

• An IEEE 802.11 defined protocol that allows for access network information retrieval in a pre-association state. ANQP has been further extended by the Wi-Fi Alliance (WFA) as part of its Passpoint program .

Access Network Provider (ANP):

• An entity that has joined the federation and serves OpenRoaming end-users by configuring the OpenRoaming RCOI(s) on its Wi-Fi equipment. Entities do not have to join the WBA in order to oeprate as an OpenRoaming ANP.

Broker:

• An entity that is a WBA member which has joined the federation and performs certain specific roles to help scale the operation of the federation. The separate roles of a broker can include:

• • Assigning WBA identities (WBAIDs) to ANPs and IDPs. Operating an issuing intermediate certification authority under the WBA's PKI and issuing certificates to ANPs and IDPs. Operating a registration authority to a third party operated issuing intermediate certification authority under WBA's PKI to enable certificates to be issued to ANPs, hub-providers and IDPs.

Closed Access Group (CAG):

• The definition of the 12 most significant bits of an OUI-36 RCOI to indicate OpenRoaming policy controls that can be enforced by ANPs and IDPs.

Identity Provider (IDP):

• An entity that has joined the federation and includes the OpenRoaming RCOI(s) in the Passpoint profile of its end-user devices and authenticates end-user devices on OpenRoaming ANP networks. Entities do not have to join the WBA in order to oeprate as an OpenRoaming IDP.

Level of Assurance (LoA):

• An ISO/IEC 29115 term that is used to define equivalent levels for handling of end-user enrollment, credential management and authentication amongst different IDPs.

OpenRoaming-Settled:

• The "base RCOI" of BA-A2-D0 that is used to indicate that the ANP expects to receive payment for providing OpenRoaming service to end-users.

OpenRoaming-Settlement-Free:

• The "base RCOI" of 5A-03-BA that is used to indicate that the ANP provides the OpenRoaming service to end-users at no cost to the IDP.

Passpoint Profile:

• Passpoint is a Wi-Fi Alliance (WFA) certification program that defines the use a Passpoint profile, that includes the user's credentials and the access network identifiers, that enables Wi-Fi devices to automatically discover and authenticate to Wi-Fi hotspots that provide Internet access .

PLMN Id:

• A unique identifier for a mobile network (cellular) operator. The identifier consists of a MCC (Mobile Country Code) and a MNC (Mobile Network Code). ITU-T Recommendation defines both MCC and MNC. The ITU allocates MCC values to national regulators who are then responsible for allocating MNC values to individual mobile network operators. defines how the PLMN Id can be sent in ANQP messages.

Roaming Consortium Identifier (RCOI):

• An RCOI identifies the groups of identity providers that are supported by the network. It is a 3-octet, or a 5-octet value carried in the 802.11 beacon information element (IE). It is also sent in the ANQP messages. Based on the access technologies, the specific link-layer protocols will be used for carrying the RCOI. RCOI is also part of the Passpoint profile.

• NOTE: OpenRoaming only uses 5-octet RCOIs.

Subscriber Identity Module (SIM):

• The SIM is traditionally a smart card distributed by a mobile operator.

WBA Identity (WBAID):

• A hierarchical namespace that is used to uniquely identify every OpenRoaming entity (ANP, IDP, broker or hub-provider).

Wireless Roaming Intermediary eXchange (WRIX):

• A framework, aimed at facilitating interconnectivity between operators and the Wi-Fi roaming hub services.

Wireless Broadband Alliance The Wireless Broadband Alliance (WBA) defines the Wireless Roaming Intermediary eXchange (WRIX) framework, aimed at facilitating interconnectivity between Wi-Fi operators and the Wi-Fi roaming hub services, as well as the Carrier Wi-Fi Services program that provides guidelines to improve customer experience on Carrier Wi-Fi networks. Both of these programs leverage the Wi-Fi Alliance specified Passpoint functionality to enable automatic and secure connectivity to Wi-Fi networks, allowing devices to be provisioned with network access credentials with minimal user interaction. WBA programs have traditionally focussed on "offloading" cell phone data from cellular networks onto Wi-Fi networks. Deployments of such systems have seen uneven adoption across geographies, with cellular operators frequently limiting their engagement to premier locations that have deployed Wi-Fi and experience a significant footfall of operator's customers. Whereas conventional Carrier Wi-Fi has focused on premier locations, the last decade has seen a continued increase in the requirements of private Wi-Fi networks to be able to serve visitors, contractors and guest users. Moreover, in most of these scenarios, the Wi-Fi network is primarily being used to support some alternative value proposition; an improved retail experience in a shopping mall, a more efficient meeting in a carpeted office, a superior stay in a hospitality venue, or a better fan experience in a sporting arena. Traditionally, this segment has made wide-scale use of captive portals and unencrypted Wi-Fi links to onboard end-users onto their networks . However, increasing concerns around sending Internet traffic over open, untrusted networks, together with the decreasing costs for cellular data, mean that end-users are less motivated to search out and attach to such "free" Wi-Fi networks, and as a consequence, captive portal conversion rates continue to decrease. As a consequence, in 2020 WBA launched its OpenRoaming federation, designed to provide a better on-boarding experience to end-users, that is seamless, scalable and secure.

OpenRoaming Architecture contrasts a conventional carrier Wi-Fi roaming system with OpenRoaming. As illustrated, conventional Wi-Fi roaming has typically been based on: IPSec tunnels established between access networks, hub-providers and identity providers used to protect exchanged signalling. Static routing of RADIUS signalling based on realm routing tables populated according to agreements between access networks and hub-providers. Passpoint primarily used with SIM based identifiers, where individual PLMN Ids are configured on the access networks WLAN equipment enabling them to be sent in ANQP messages, and cellular providers enable Passpoint based SIM authentication in end-user devices. EAP-AKA based Passpoint authentication exchanged between the Supplicant in the end-user device and the EAP Server in the cellular provider's network. A primary focus on carrier based identities where the end-user has a billing relationship with the carrier. In contrast, OpenRoaming is based on: RadSec signalling secured using mTLS with certificates issued under WBA's private certification authority. Dynamic routing of RADIUS based on DNS-based discovery of signalling peers, as specified in . Passpoint based network selection based on 36-bit Roaming Consortium Organization Identifiers (RCOIs), where WBA defines the use of the 12 most significant bits of the 36-bit RCOI to embed closed access group policies. Passpoint authentication that can use any suitable EAP method. Encompassing new identity providers who do not necessarily have a billing relationship with their end-users. Example EAP methods used with Passpoint include EAP-TLS, EAP-SIM, EAP-AKA, EAP-AKA' and EAP-TTLS with MS-CHAP-V2 that are included in Table 4 of the Passpoint specification . In addition to these 5 EAP methods, Wi-Fi devices are available that can be configured to use different EAP type with Passpoint, including Passpoint with Protected EAP (PEAP) , EAP-TEAP and EAP-FAST outer methods, together with alternative inner methods to MS-CHAP-V2 used inside EAP-TTLS, including EAP-TLS. Because OpenRoaming ANPs have no direct relationship with OpenRoaming IDPs that decide the credential type and EAP method to use when authenticating end-user devices, OpenRoaming ANPs SHOULD ensure that all EAP Methods compatible with Passpoint can be used to authenticate end-user devices.

|Provider|<------>|Provider|<------>|Network | | | RADIUS | | RADIUS | | RADIUS | | | NAS | | RADIUS | | RADIUS | | RADIUS | | |<------>| proxy |<------>| proxy |<------>| Server | |Passpoint| IPSec +--------+ IPSec +--------+ IPSec +--------+ |PLMNId(s)| +---------+ /|\ | \|/ +---------+ A) Conventional Carrier Wi-Fi |Passpoint| | device | | with | | PLMN-Id | | profile | +---------+ +---------+ +---+ +--------+ | Visited |<----------------->|DNS|<------------------>|Identity| | Wi-Fi | DNS based peer +---+ Configure NAPTR, |Provider| | Network | discovery SRV and A/AAAA |Network | | | records | | | NAS | | RADIUS | | |<------------------------------------------>| Server | |Passpoint| RadSec/TLS secured using mTLS +--------+ | RCOI(s) | and WBA PKI +---------+ /|\ | \|/ +---------+ B) OpenRoaming |Passpoint| | device | | with | | RCOI(s) | | profile | +---------+ ]]>

Identifying OpenRoaming Entities All OpenRoaming providers (access, identity and hub) and OpenRoaming brokers are allocated a WBA Identity (WBAID). The WBAID is defined to be transported in the RADIUS Operator-Name attribute (#126) . WBA has been allocated the Operator Namespace identifier 0x34 "4" to identify an Operator-Name attribute carrying a WBAID. The WBAID is a hierarchical namespace that comprises at its top level the identity allocated by WBA to a WBA Member and is of the form shown in where the optional 2 upper case characters represent an ISO-3166 Alpha-2 country code e.g., "WBAMEMBER:US".

When operating as an OpenRoaming broker, the WBA Member is able to allocate subordinate identities to OpenRoaming providers who are not WBA members by pre-pending a subordinate identity , plus "." (%x2e) to the Member's WBAID, e.g., a broker assigned the WBAID "WBAMEMBER:US" by the WBA is able to assign the WBAID "OPENROAMINGPROVIDER.WBAMEMBER:US" to a third-party ANP/IDP who has agreed terms with the broker and joined the federation. In this way, any receiving entity of a WBAID can identify the WBA Member who is acting as an OpenRoaming broker to the provider by assigning it an identity.

Scaling Secured Signalling As described in , the OpenRoaming legal framework does not assume any direct relationship between ANPs and IDPs. In order to scale the secured signalling between providers, the federation makes use of a Public Key Infrastructure (PKI) using a private Certificate Authority specifically designed to secure the operations of the roaming federation. WBA and its members have published the WBA Certificate Policy that defines the policies which govern the operations of the PKI components by all individuals and entities within the infrastructure. The OID for Wireless Broadband Alliance is:

• { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) The Wireless Broadband Alliance(14122) }

The Wireless Broadband Alliance organizes its OID arcs for the Certificates Policy Documents using the object identifier 1.3.6.1.4.1.14122.1.1. At the time of writing, the current certificate policy is 1.3.6.1.4.1.14122.1.1.7. This Certificate Policy is based on a 4-level hierarchy, as illustrated in .

Certificates issued under the WBA PKI are used by Entities to perform mutual authentication with other Entities and to secure RadSec signalling that carries EAP-based Passpoint authentication. This is typically between a RadSec client in the OpenRoaming ANP's network and an RadSec Server in the OpenRoaming IDP's network, although a provider can decide to outsource the operation of the RadSec endpoint to a third party provider. OpenRoaming is a distributed federation that lacks a centralized RADIUS element for identifying and troubleshooting signalling issues. Instead, the WBA operates cloud-based systems capable of verifying the correct configuration of DNS and TLS endpoints for OpenRoaming IDPs that have registered their realms with the WBA. This baseline testing by the WBA ensures that ANPs and IDPs can establish a TLS connection, such as when an end-user from an IDP roams into the coverage area of Wi-Fi networks operated by an ANP. To provide a scalable system that enables access and identity providers to collaboratively troubleshoot and resolve issues, the WBA Certificate Practice Statement REQUIRES the Subject Alternative Name (SAN) attribute in issued end-entity certificates includes a contact email address responsible for handling issues raised by third-party providers. The OpenRoaming legal framework requires ANPs and IDPs to make reasonable efforts to support troubleshooting procedures. This includes monitoring the email address listed in the SAN attribute of the certificate and responding to any issues raised by legitimate third parties.

IDP Discovery

Dynamic Discovery OpenRoaming defines the use of dynamic discovery by which an ANP discovers the IP address of the IDP's RadSec server. Whereas defines the use of separate service tags for identifying RADIUS Authentication ("aaa+auth") and RADIUS Accounting ("aaa+acct") servers, OpenRoaming uses the "aaa+auth" tag to identify the IP address of a RadSec server that supports both RADIUS authentication and accounting. additionally defines the use of DNS to enable the dynamic discovery of a RADIUS endpoint for supporting dynamic authorization services, i.e., for RADIUS Change of Authorization (CoA) and Disconnect Message (DM) support. OpenRoaming does not use dynamic discovery for dynamic authorization, instead defining the use of "reverse CoA" that allows an IDP to send CoA packets in "reverse" down a RADIUS/TLS connection that was previously established by an ANP originated signaling exchange, as defined in .

Discovery of EAP-AKA/AKA' Servers Passpoint defines the use of EAP-AKA' based authentication which uses the 3GPP 23.003 defined realm of wlan.mnc<mnc>.mcc<mcc>.3gppnetwork.org, where <mcc> represent an E.212 Mobile Country Code and <mnc> represents the E.212 Mobile Network Code allocated to the IDP. GSMA is responsible for operating the 3gppnetwork.org domain and GSMA IR.67 limits access to the DNS systems supporting such records to those systems connected to the inter-PLMN IP backbone (known as "GRX/IPX"). As OpenRoaming ANPs do not connect to this inter-PLMN backbone, then conventional realm based lookup cannot be used over the Internet to discover the RadSec server supporting EAP-AKA' authentication. GSMA IR.67 does allow systems to be discoverable from the public Internet, specifically calling out the use of the pub.3gppnetwork.org sub-domain name for such procedures. In order for ANPs to dynamically discover the RadSec server supporting EAP-AKA' authentication, GSMA has defined the use of the wlan.mnc<mnc>.mcc<mcc>.pub.3gppnetwork.org by OpenRoaming systems. This means that whenever a RadSec client receives a user-name containing an NAI formatted as user@wlan.mnc<mnc>.mcc<mcc>.3gppnetwork.org, the dynamic peer detection functionality MUST insert ".pub" into the realm and perform DNS based dynamic discovery using the wlan.mnc<mnc>.mcc<mcc>.pub.3gppnetwork.org domain name. The RADIUS user-name attribute MUST NOT be similarly modified. IR.67 defines the procedure by which a cellular operator can request the delegation of their mnc<mnc>.mcc<mcc>.pub.3gppnetwork.org sub-domain. GSMA PRD IR.67 also allows an MNO to delegate the entire mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org sub-domain which could have already occurred, e.g., to enable use of the epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org domain used with 3GPP's Wi-Fi calling service. Using this approach, a cellular operator operating as an OpenRoaming IDP can authenticate their end-users on third party ANP Wi-Fi networks.

Proving a Discovered RadSec Server is Authoritative for a Realm The OpenRoaming preferred approach to dynamically discover the RadSec server IP address serving a particular realm or set of realms is to use DNS records that are protected with DNSSEC . However, GSMA has not enabled DNSSEC on its 3gppnetwork.org domain, meaning that DNSSEC cannot be applied on the publicly resolvable domains under pub.3gppnetwork.org. Because of this situation, OpenRoaming does not currently mandate operation of DNSSEC. If the DNS records for a realm are not protected with DNSSEC, because the realm has been provided directly by the OpenRoaming end-user, the IDP SHOULD ensure that the discovered RadSec server(s) supporting its realm(s) is/are configured with a WBA-PKI server certificate that includes the realm(s) used in the dynamic peer detection in the certificate SubjectAltName. Where the DNS records are protected with DNSSEC, the IDP SHOULD ensure that the discovered RadSec server(s) supporting its realm(s) is/are configured with a WBA-PKI server certificate that includes the derived name(s) from the secured DNS NAPTR/SRV query in the certificate SubjectAltName. Where the OpenRoaming IDP has offloaded the operation of RadSec termination to a third party hub-provider that is responsible for supporting a number of independent realms, the hub-provider SHOULD ensure that the discovered RadSec server(s) supporting the independent realms from its partner IDPs is/are configured with a WBA-PKI server certificate that includes the derived name(s) from the DNS NAPTR/SRV query in the certificate SubjectAltName.

Co-existence with Other Federations Other federations which want to interface to the OpenRoaming federation may use dynamic discovery with distinct NAPTR application service tags to facilitate integration. For example, an eduroam service provider can use the use the "x-eduroam" application service tag, specified in , to discover the home institution's RadSec peer for authentication, and OpenRoaming ANPs can use the "aaa+auth" tag to discover a separate RadSec peer that can be defined for handling all inter-domain authentications. Where a separate inter-federation RadSec peer is not used, the other federation AAA operating as an OpenRoaming IDP needs to determine which certificate chain to return in its ServerHello message. An OpenRoaming ANP operating with TLS 1.3 SHOULD use the "certificate_authorities" extension in its ClientHello message to indicate that the ANP supports the WBA PKI Certification Authority trust anchor. Similarly, an OpenRoaming ANP operating using TLS 1.2 SHOULD use the "trusted_ca_keys" extension in its ClientHello message to indicate the DistinguishedName of the WBA PKI Certification Authority whose root keys the ANP possesses. The federation AAA operating as an OpenRoaming IDP MAY use information in the ClientHello extension to guide its certificate selection.

Connection Management for Dynamically Discovered RadSec Peers The procedures for connection management for dynamically discovered peers depends on whether the ANP supports reverse CoA functionality, as defined in .

ANPs not supporting reverse CoA An OpenRoaming ANP MAY operate with a short TCP idle timeout, sufficient to complete the RADIUS Access-Request exchange and the initial RADIUS Accounting-Request exchange with Acct-Status-Type set to "Start". Subsequent RADIUS Accounting-Request messages to the IDP may require TLS resumption, for example, if no other inbound roamers from the IDP are active on the ANP's network.

• NOTE: When performing TLS resumption, the ANP MUST consider the server IP address stale if its corresponding DNS record has expired and perform a new DNS query to resolve the current IP address.

Operation using short TCP-idle timeouts avoids the need for the operation of an additional RADIUS application watchdog. In such cases, ANPs are NOT REQUIRED to support Status-Server extension as a RADIUS application-level watchdog.

ANPs supporting reverse CoA An OpenRoaming ANP supporting the reverse CoA functionality defined in SHOULD manage connections such that the RadSec connection to the dynamically discovered peer is considered as "temporarily static" while active RADIUS sessions exist that may require the sending of future CoA packets. While the connection is "temporarily static", the ANP MUST monitor the RadSec connection liveness. The ANP SHOULD use the Status-Server extension, defined in for monitoring the liveness of a RadSec connection. IDPs and hubs supporting OpenRoaming settled-service MUST respond to Status-Server requests.

• NOTE 1: OpenRoaming recognizes that despite recommending RADIUS clients SHOULD NOT generate RADIUS Access-Request packets solely to see if a server is alive, some OpenRoaming ANPs do use RADIUS Access-Request for such purposes. In such cases, the Access-Request MUST be sufficient for the IDP to reject the request without performing an Access-Challenge.

The OpenRoaming ANP supporting reverse CoA MUST NOT configure any TCP-idle timeout shorter than the shortest inter-RADIUS message duration, (e.g., the accounting interim period or connection liveliness checking repetition period). Reconnection procedures SHOULD follow section 3.8.1 of . This section REQUIRES the ANP implement an algorithm for handling the timing of such reconnection attempts that includes an exponential back-off.

• NOTE 2: When performing TLS-reconnection, the ANP MUST consider the server IP as stale when its corresponding DNS record has expired and perform a new DNS query to resolve the current IP address.

• NOTE 3: This does not prevent an ANP performing a new DNS query, e.g., if a reconnection attempt fails in case the server has had its IP address configuration changed unexpectedly.

Load Balancing RadSec Connections An ANP MAY perform load balancing on dynamically discovered RadSec connections, according to the ANPs load balancing policies. Load balancing can trigger the opening of a new TLS connection to a RadSec server even if an existing TLS session is present. ANPs that support reverse CoA MUST use the same TLS session for sending RADIUS Access-Request and RADIUS Accounting-Request messages that correspond to the same individual user session.

Connection Management for IDP RadSec Servers Since TCP-idle timeout and reverse CoA support are ANP policies, all IDPs and hubs SHOULD enable support for Status-Server extension, as specified in . Dynamically established connections between ANPs and IDPs with frequent authentication exchanges may never trigger idle timeouts, potentially hindering IDPs from updating RadSec server IP address configurations. IDPs can operate their DNS systems and RadSec servers TCP configuration to facilitate RadSec server IP address re-configuration. For example, a DNS TTL of 86400 seconds coupled with a maximum TCP connection lifetime of 86400 seconds, ensures that connections between ANPs and IDPs experiencing frequent authentications are re-established using an updated DNS record at least once every 24 hours. In such cases, if the session was closed by the RadSec server, the ANP SHOULD NOT consider the closure as normal. If the ANP supports reverse CoA, the ANP SHOULD follow section 3.8.1 of that permits the triggering of an immediate reconnection to the RadSec server by the ANP.

OpenRoaming Passpoint Profile

OpenRoaming Policy Controls In order to avoid possible fragmentation of roaming federations, OpenRoaming recognizes that there is a need to permit OpenRoaming to be integrated into a variety of different use-cases and value propositions. These use-cases include scenarios where providers are able to enforce policy controls of which end-users are authorized to access the service. The realization of authorization policy controls in the OpenRoaming federation is a balance between the requirements for fine grain policy enforcement versus the potential impact of policy enforcement (access rejection) on the end-user experience. Such a level of control is realized using Closed Access Group (CAG) based policies. A Closed Access Group identifies a group of OpenRoaming users who are permitted to access one or more OpenRoaming access networks configured with a particular CAG policy. These Closed Access Group policies are encoded using one or more Roaming Consortium Organization Identifiers (RCOIs), first defined in Passpoint Release 1.0, and well supported across the smartphone device ecosystem.

• NOTE: encoding CAG policies in OpenRoaming using one or more RCOIs is aimed at delivering an equivalent functionality to the CAG policies encoded in 3GPP using one or more CAG-IDs.

OpenRoaming Closed Access Group Policies OpenRoaming defines the use of multiple RCOIs to facilitate the implementation of Closed Access Group policies across the federation. The currently defined RCOIs are: OpenRoaming-Settled: BA-A2-D0-xx-x OpenRoaming-Settlement-Free: 5A-03-BA-xx-x shows how the 24-bit length OpenRoaming RCOIs are further extended into 36-bit length OUI-36s with additional context dependent identifiers used to encode specific Closed Access Group policies. Following Passpoint Release 1.0 specification, only when there is a bitwise match of all 36 bits of the configured RCOI in the WLAN equipment and the Passpoint profile configured in the end-user device will an EAP authentication be triggered. The encoding of Closed Access Group policies is defined so that the "no-restrictions" policy is encoded using the 12-bit value "00-0", i.e., 54-03-BA-00-0 represents a policy that accepts all OpenRoaming settlement-free end-users onto a particular ANP installation.

Level of Assurance Policies The format of the Level of Assurance (LoA) field is as shown in .

The baseline identity proofing requirement on IDPs ensures that all OpenRoaming identities are managed with at least a medium level of assurance (LoA level 2) for end-user enrollment, credential management and authentication, as specified in ISO/IEC 29115 . The LoA field is used to support ANPs which operate in regulatory regimes that require enhanced identity proofing to be used in the provision of credentials on OpenRoaming devices, equivalent to LoA level 3 in ISO/IEC29115 . In such a scenario, the ANP can set the LoA bit field to 1 in all configured RCOIs to ensure that only identities provisioned using enhanced LoA 3 procedures can access via the ANP's network. Any IDP that manages its identities according to ISO/IEC 29115 LoA level 2 MUST NOT configure any RCOI in their end-users' Passpoint profile with the LoA field set to "1". Conversely, an IDP that manages its identities according to ISO/IEC 29115 LoA level 3 MAY configure multiple RCOIs in their end-users' Passpoint profile, including RCOIs with the LoA field set to "0" and RCOIs with the LoA field set to "1".

Quality of Service Policies

Access Network Requirements One of the challenges faced by users of Wi-Fi hotspots is when the Wi-Fi network is configured sub-optimally and results in a poor user experience. Often the only remedy open to a user it to disable the Wi-Fi interface on their smartphone and continue to use cellular data. This is especially the case where the Wi-Fi hotspot has been automatically selected with no user intervention. As a consequence, OpenRoaming defines specific service tiers across the federation and uses the QoS field to differentiate between different tiers. The format of the QoS field is shown in .

The "Bronze" and "Silver" values of QoS field are used to identify specific minimum quality of service policy aspects. The bronze service tier corresponds to the following: The availability of OpenRoaming service when used to access the Internet measured during scheduled operations across the ANP's network exceeds 90% over any one month period. The ANP shall ensure that the maximum download speed that end-Users can access the Internet shall be at least 50 megabits per second. During the busy hour, the aggregate bandwidth used to receive Internet service on the ANP's network is sufficient to enable each and every authenticated and authorized OpenRoaming end-user to simultaneously receive a sustained 256 kilobits per second connection. The silver service tier corresponds to the following: The availability of OpenRoaming service when used to access the Internet measured during scheduled operations across the ANP's network exceeds 95% over any one month period. The ANP shall ensure that the maximum download speed that end-users can access the Internet shall be at least 100 megabits per second. During the busy hour, the aggregate bandwidth used to receive Internet service on the ANP's network is be sufficient to enable each and every authenticated and authorized end-user to receive a sustained 512 kilobits per second connection. At least 10% of authenticated and authorized users are able to stream video content at a downlink rate of at least 5 megabits per second (when measured over a one-minute interval) over all of the ANP's OpenRoaming enabled Wi-Fi networks. The authenticated and authorized end-users are able to stream video from one or more third party content distribution networks with an end-to-end latency of less than 150ms from all of the ANP's OpenRoaming enabled Wi-Fi networks. The QoS field can be used by those IDPs that are only interested in providing their end-users with a higher quality service level when automatically authenticated onto an OpenRoaming network. For example, an IDP configures the QoS field as bronze in a Passpoint profile that uses the "5A-03-BA" settlement free RCOI and configures the QoS field as silver in a Passpoint profile that uses the "BA-A2-D0" OpenRoaming-settled paid service. ANPs that only support the bronze service tier MUST set the QoS Field to "00" in all RCOIs configured on their WLAN equipment. ANPs that support the silver service tier MAY configure multiple RCOIs on their WLAN equipment that include values where the QoS field is set to "01" and values where the QoS field is set to "00". Exceptionally, ANPs that operate OpenRoaming installations on moving platforms are permitted to deviate from the normal OpenRoaming service level requirements listed above. This is because such installations can necessitate use of cellular-based backhaul and/or backhaul via Non-Terrestrial Networks (NTN) which may not be able to meet the OpenRoaming minimum "bronze" service level requirements. If an ANP wants to benefit from such deviations, it MUST signal using the WLAN-Venue-Info attribute that it is operating in a venue category identified using a Venue Group value of "10", which is defined in Section 8.4.1.34 of as being used for vehicular installations. In such cases, the OpenRoaming ANP MAY signal one or more WBA-Custom-SLA vendor specific attributes to indicate one or more (availability, per-user sustained bandwidth) tuples to the IDP. OpenRoaming also defines the ability of the ANP to signal additional real-time metrics associated with the Wi-Fi connection to an end-user, using the enhanced syntax for the RADIUS Connect-Info attributes as defined in . This information can be used by an IDP to derive a quality metric for the performance of the ANP's OpenRoaming Wi-Fi network.

Identity Provider Requirements Irrespective of the service-levels supported by their users, the IDP shall ensure that the availability of their authentication service measured during scheduled operations shall exceed 99% over any one month period.

Rationale for Busy Hour Sustained Throughput Values The ANP requirements for sustained busy hour throughput requirements defined in are based on equating a notional per month consumption to a sustained busy hour throughput. The following calculation represents the mapping of sustained throughput to monthly consumption. Busy hour sustained throughput = 256 kilobits per second Busy hour consumption = 256 x 1024 x 3600 / 8 = 118 megabytes per hour Daily consumption, assuming 7% consumed in busy hour = 118 / 0.07 = 1.69 gigabytes Monthly consumption, assuming 22 busy days per month = 1.69 x 22 = 37.1 gigabytes/month Comparing to a cellular usage, we need to use smartphone consumption figures that precludes Wi-Fi as well as broadband specific fixed wireless access subscriptions. Using an example 10 gigabytes/month consumption per cellular subscription, it is evident that OpenRoaming bronze is dimensioned to accommodate 3.7 times the example cellular traffic, or 78% of total traffic when cellular and Wi-Fi are combined. Similarly, OpenRoaming silver is dimensioned to carry 88% of total traffic when cellular and Wi-Fi are combined.

Privacy Policies The baseline privacy policy of OpenRoaming ensures the identities of end-users remain anonymous when using the service. The WBA WRIX specification specifies that where supplicants use EAP methods that support user-name privacy, i.e., which are compatible with the "@realm" (or "anonymous@realm") (outer) EAP-Identifier, then the supplicant SHOULD use the anonymized outer EAP identifier. Supplicants supporting other EAP methods SHOULD support EAP method specific techniques for masking the end-user's permanent identifier, for example pseudonym support in EAP-AKA/AKA' and/or enhanced IMSI privacy protection . OpenRoaming IDPs SHOULD support and enable the corresponding server-side functionality to ensure end-user privacy is protected. The WBA WRIX specification also recognizes that the privacy of end-users can be unintentionally weakened by the use of correlation identifiers signalled using the Chargeable-User-Identity attribute (#89) and/or the Class attribute (#25) in the RADIUS Access-Accept packet. The WBA WRIX Specification recommends that the default IDP policy SHOULD ensure that, when used, such correlation identifiers are unique for each combination of end-user/ANP and that the keys and/or initialization vectors used in creating such correlation identifiers SHOULD be refreshed at least every 48 hours, but not more frequently than every 2 hours. This 2 hour limit is designed to assist the ANP in performing autonomous troubleshooting of connectivity issues from authentic end-users/devices that are repeatedly re-initiating connectivity to the ANP's network and/or to assist the ANP in identifying a new session originated by an authentic user/device that has previously been identified by the ANP as having violated the OpenRoaming end-user terms and conditions . When using typical public Wi-Fi session durations, it is estimated that, with this 2 hour restriction, the ANP will be able to correlate a RADIUS Access-Request/Access-Accept exchange that immediately follows a RADIUS Accounting-Request stop message in over 50% of the sessions. In contrast to this default policy, there can be scenarios where the ANP desires to derive value from its OpenRoaming settlement-free service by analysing aggregate end-user behaviour. Whereas the use of aggregated end-user information does not violate the OpenRoaming privacy policy, the derivation of such can benefit from the ANP being able to uniquely identify end-users. In order to support such scenarios, the OpenRoaming closed access group policies include the PID field. The PID field can be used to support scenarios where the end-user has consented with their IDP that an immutable end-user identifier can be signalled to the ANP in the RADIUS Access-Accept. The format of the PID field is illustrated in . The PID field can be configured to "1" in the RCOIs used by those ANPs that want to be be able to account for unique OpenRoaming end-users. The OpenRoaming IDP terms ensure subscribers MUST explicitly give their permission before an immutable end-user identity is shared with a third party ANP. When such permission has not been granted, an IDP MUST NOT set the PID field to "1" in any of the RCOIs in its end-user Passpoint profiles. When such permission has been granted, an IDP MAY configure multiple RCOIs in their end-users' Passpoint profile, including RCOIs with the PID field set to "1".

ID-Type Policies The ID-Type field can be used to realize policies which are based on the business sector associated with the identity used by the IDP. The format of the ID-Type field is illustrated in . All IDPs configure at least one RCOI in their end-user's Passpoint profile with ID-Type set to "0000" (Any identity type is permitted). An IDP MAY configure additional RCOIs in their end-users' Passpoint profile with an ID-Type representing the sector type of IDP. An ANP what wants to serve all end-users, irrespective of sector, configures RCOIs in the WLAN equipment with ID-Type set to "0000". Alternatively, an ANP which operates a sector specific business that only desires to serve a subset of OpenRoaming end-users MAY set the ID-Type to their desired sector in all configured RCOIs.

On-boarding Credential Policies The format of the on-boarding credential policy (On-board) field is as shown in .

The On-board field is used to identify closed access group policy aspects related to whether the identity/profile is long-lived, or whether the identity/profile is short-lived. Short-lived profiles are intended to only be used to provide connectivity such that the procedure for configuring a long-lived identity/profile can be performed. Sessions authorized with short-lived credentials MUST have a session-timeout value of less than 300 seconds.

Prioritizing Policies The definition of OpenRoaming closed access group policies assumes the configuration of multiple RCOIs in ANP WLAN equipment and IDP end-user devices. When a device has multiple Passpoint profiles matching the ANP's Closed Access Group policy, an OpenRoaming ANP may want to prefer OpenRoaming subscribers use a particular IDP's profile when attaching to its access network. Such a preference can be because the OpenRoaming ANP has a preferential relationship with certain OpenRoaming IDPs. The OpenRoaming ANP is able to use the Home SP preference functionality defined in Passpoint to prioritize the use of a particular profile by a Passpoint enabled device. In such a scenario, the ANP configures the Domain Name list to include the FQDN(s) associated with the profile(s) to be prioritized.

OpenRoaming RADIUS Profile The OpenRoaming RADIUS profile is based on the WBA WRIX Specification which in turn are derived from and . All ANPs MUST support RADIUS Accounting for all OpenRoaming sessions, irrespective of which RCOIs are supported, i.e., for both settled and settlement free service. All IDPs MUST respond to any RADIUS Access-Request and Accounting-Request packet received. Additionally, OpenRoaming defines the use of the following RADIUS attributes.

Operator-Name As described in , OpenRoaming uses the Operator-Name (#126) attribute to signal the WBAID of the OpenRoaming ANP. All ANPs MUST support the Operator-Name attribute and use it to signal the WBAID of the OpenRoaming ANP, using the WBA allocated Operator Namespace identifier, as specified in . Exceptionally, if the RADIUS client does not support the WBA allocated namespace identifier, the WBAID MAY be encoded in the realm namespace, by using the base64 encoded WBAID as a subdomain to the realm "wballiance.com". For example,

• ANP1.INTERMEDIARY2:PT

is encoded as

• QU5QMS5JTlRFUk1FRElBUlkyOlBU.wballiance.com

Chargeable-User-Identity All OpenRoaming ANPs MUST support the Chargeable-User-Identity attribute (#89) and indicate such by including a CUI attribute in all RADIUS Access-Request packets. An ANP that has configured the OpenRoaming-Context PID Field set to "1" MAY treat a RADIUS Access-Accept received without a CUI attribute as an Access-Reject. An ANP that has configured the OpenRoaming-Context PID Field set to "0" MUST NOT treat any RADIUS Access-Accept received without a CUI attribute as an Access-Reject. When an end-user has explicitly given their permission to share an immutable end-user identifier with third party ANPs, the CUI returned by the IDP MUST be invariant over subsequent end-user authentication exchanges between the IDP and the ANP.

Location-Data/Location-Information All OpenRoaming ANPs MUST support signalling of location information using . As a minimum, all OpenRoaming IDPs need to be able to determine the country in which the OpenRoaming ANP operates. The OpenRoaming legal framework described in serves as an "out-of-band agreement" as specified in clause 3.1 of . Hence, all OpenRoaming ANPs MUST include the Location-Data attribute (#128) in the RADIUS Access-Request packet, where the location profile is the civic location profile that includes the country code where the ANP is located . When the OpenRoaming ANP supports the OpenRoaming-Settled RCOI ("BA-A2-D0"), the RADIUS Access-Request packet MUST include the Location-Data attribute (#128) where the location profile is the civic location profile containing Civic Address Type information that is sufficient to identify the financial regulatory regime that defines the taxable rates associated with consumption of the ANP's service. OpenRoaming also defines the optional use the geospatial location profile as specified in . ANPs MAY signal coordinate-based geographic location of the NAS or end-user device. The OpenRoaming Privacy Policy restricts the use of all location information signalled to an IDP for either: Making service authorization decisions based on the location of the ANP's wireless network; or Compliance with applicable law, or law enforcement requests.

Session-Timeout An OpenRoaming ANP receiving a RADIUS Access Accept message including a Session-Timeout attribute MUST operate according to . An IDP authenticating using a credential associated with a Passpoint profile with an RCOI where the On-board value is set to 1, as defined in , MUST set the session-timeout value to less than 300 seconds in the RADIUS Access-Accept message.

Acct-Session-Id All OpenRoaming enabled ANPs MUST support attribute Acct-Session-Id . If an OpenRoaming IDP receives a RADIUS Access-Request message without an Acct-Session-Id attribute, it SHOULD reject the Access-Request. When supported, the Acct-Session-Id attribute SHOULD be temporally unique within an ANP's access network. An OpenRoaming IDP that receives a RADIUS Accounting-Request message without either an Acct-Session-Id or an Acct-Multi-Session-Id corresponding to an authenticated RADIUS session SHOULD create a log of the message non-compliance, including the WBAID of the ANP.

Acct-Multi-Session-Id All OpenRoaming enabled ANPs configured to generate multiple related accounting sessions for a single EAP-Supplicant roaming between Wi-Fi Access points MUST support attribute Acct-Multi-Session-Id . The Acct-Multi-Session-Id attribute SHOULD be temporally unique within an ANP's access network. An OpenRoaming IDP that receives a RADIUS Accounting-Request message without either an Acct-Session-Id or an Acct-Multi-Session-Id corresponding to an authenticated RADIUS session SHOULD create a log of the message non-compliance, including the WBAID of the ANP.

Event-Timestamp All OpenRoaming ANPs MUST include the Event-Timestamp attribute in all RADIUS Accounting-Request messages.

Connect-Info An OpenRoaming ANP MAY include the RADIUS Connect-Info (#77) attribute in RADIUS messages sent to an IDP, as specified in . When included, the ANP SHOULD use the syntax defined in to signal Wi-Fi network connection metrics to an OpenRoaming IDP. An IDP authenticating an OpenRoaming end-user MAY use the information signalled in the Connect-Info attribute when making authorization decisions. The ANP MAY use the enhanced Connect-Info syntax to signal real-time information, including: transmit and receive bit rates, received signal strength indicator (RSSI), frame loss rate, frame retry rate, and the Wi-Fi global operating class(es) associated with the connection, as defined in Annex E of . When supported by the ANP, these quality metrics SHOULD be included in both RADIUS Access-Request and RADIUS Accounting-Request messages. The OpenRoaming legal framework (see ) ensures that IDPs that do not separately agree to terms with an ANP governing use of Wi-Fi network connection metrics MUST solely process signaled performance data for the purposes of making service authorization decisions and network troubleshooting, and are prohibited from disclosing such data to any third party except as necessary for direct network troubleshooting with the originating ANP. When included in the RADIUS Access-Request and initial RADIUS Accounting-Request message, because the raw samples used to calculate the metrics will be restricted by the number of IEEE 802.11 frames over which the calculation are based, the transmit bit rates, receive bit rates and RSSI level MAY correspond to the instantaneous value of the specific parameter. In other cases, i.e., where the Connect-Info attribute is signaled in RADIUS Accounting-Request messages with Acct-Status-Type set to Interim-Update or Stop, the ANP SHOULD use multiple measurements when calculating the reported value: the reported transmit and receive bit rates SHOULD represent the maximum values experienced since the last time the connect-info was signaled, i.e. the "ALGO" term SHOULD be set to "MAX". the received signal strength indicator (RSSI) SHOULD represent the average RSSI value, where the average value calculated MAY be either a linear average or an exponential weighted average, i.e. the "ALGO" term SHOULD be set to "AVG". frame loss rate and frame retry rate SHOULD represent the accumulated ratio, i.e. the "ALGO" term SHOULD be set to "ACC".

Enhanced Reply-Message Reply-Message was originally defined in as being forbidden from being included in any RADIUS message containing an EAP-Message attribute. This was to prevent earlier systems from attempting to interwork the Reply-Message text into an EAP Notification packet. In contrast to using Reply-Message to signal a displayable text string to authenticating users, WBA's WRIX framework defines the re-use of the attribute in WRIX-based Passpoint networks to signal additional information from the IDP to the ANP, specifically regarding why a connection has been rejected. The message received MUST NOT be shown to end-users. The enhanced reply-message is encoded using UTF-8 characters. The WBA defines additional information is appended after the NUL ASCII character (0x00). The ABNF syntax of the Reply-Message is shown in .

WBA-Identity-Provider The Operator-Name attribute allows the WBAID of the ANP to be signalled to the IDP. In the reverse direction, the IDP MUST use the WBA-Identity-Provider vendor specific attribute to signal the WBAID of the IDP back to the ANP. In this case the first character of the Identity-Provider attribute identifies the WBAID namespace and is equal to "4" (0x34).

WBA-Offered-Service The ANP MAY use the WBA-Offered-Service vendor specific attribute to signal the highest OpenRoaming service tier supported on its network . If a RADIUS Access-Request is received without either a WBA-Offered-Service or WBA-Custom-SLA attribute, the IDP SHOULD assume that the authorization request is associated with the OpenRoaming Bronze service.

WLAN-Venue-Info The ANP MAY use the WLAN-Venue-Info attribute to signal the category of venue hosting the WLAN.

WBA-Custom-SLA When the ANP uses the WLAN-Venue-Info attribute to signal that the venue hosting the WLAN is a vehicular installation, the ANP SHOULD use the WBA-Custom-SLA vendor specific attribute to indicate one or more (availability, per-user sustained bandwidth) tuples to the IDP.

Filter-Id If the IDP accepts the offered service corresponding to the WBA-Offered-Service attribute, then it MUST copy the contents of the text string received in the WBA-Offered-Service attribute and include the same text string in a RADIUS Filter-Id attribute returned in the Access-Accept message. If the IDP accepts the offered service corresponding to the WBA-Custom-SLA attribute, then the IDP shall include the text string "OpenRoaming Custom" in the RADIUS Filter-Id attribute returned in the RADIUS Access-Accept message.

Operator-NAS-Identifier An OpenRoaming ANP supporting the Reverse CoA functionality defined in , MAY use the Operator-NAS-Identifier (#241.8) as specified in . When received by the IDP, the Operator-NAS-Identifier attribute MUST be stored along with any end-user session identification attributes. When sending a CoA packet for an end-user session, the IDP MUST include verbatim any Operator-NAS-Identifier it has recorded for that session.

Reverse Change of Authorization The connection management procedures described in ensure that an ANP supporting Reverse CoA is reachable from an IDP whenever an IDP's OpenRoaming user is active on an ANP's OpenRoaming wireless network. This reachability allows the IDP, or its authorized hub, to send a Change of Authorization (CoA) request packet to the ANP in "reverse" over the existing TLS connection, and for the ANP to send responses towards the message originator. ANPs and hubs supporting OpenRoaming settled SHOULD support the Reverse CoA in RADIUS/TLS defined in . IDPs supporting OpenRoaming settled operation MAY support the Reverse CoA in RADIUS/TLS defined in , where the CoA refers to either the CoA-Request or Disconnect-Request messages as defined in . There is no explicit negotiation of support for Reverse CoA between OpenRoaming ANPs, hubs and IDPs. An IDP supporting Reverse CoA SHOULD interpret the lack of response to a CoA-Request or Disconnect-Request as being due to the silent discard of the packet by an un-supporting ANP, or an intermediate hub. The CoA originator SHOULD associate the reverse CoA capability with each ANP, as identified by the Operator-Name attribute (#126). The CoA originator that has identified an un-supporting ANP SHOULD cease sending further Reverse CoA requests to that ANP. IDPs and hubs supporting Reverse CoA MUST be able to forward the CoA packet to the correct next hop based on the TLS session used to support the user-session. When load balancing is employed, the routing of reverse CoA packets MUST account for the possibility that multiple CoA servers can be associated with the same Operator-Name attribute: The IDP and hub MUST maintain session affinity or "stickiness" to the specific TLS session corresponding to the user session, so that CoA packets are routed to the same server instance that established the original session. The routing logic SHOULD use additional session identification attributes, such as Charegable-User-Id, Acct-Session-Id, Operator-Name, Called-Station-Id and/or Operator-NAS-Identifier, to disambiguate among multiple possible next hops when load balancing is in effect. If multiple TLS sessions exist for the same WBAID due to load balancing, the IDP SHOULD select the appropriate next hop based on the user session context to avoid routing CoA packets to an incorrect CoA server. The CoA packet is sent to the next proxy/CoA Server according to the routing logic. This process continues with any subsequent proxies until the packet reaches the ANP's CoA server. IDPs MUST include the Operator-Name attribute in all CoA-Request and Disconnect-Request packets, as described in . The value of the Operator-Name attribute MUST be the value that was recorded earlier for that user session. If a proxy/CoA Server receives a CoA packet with an unknown Operator-Name, the server MUST operate as per and return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable"). The ANP MAY use the Operator-NAS-Identifier as specified in . When received by the IDP, the Operator-NAS-Identifier attribute MUST be stored along with any user session identification attributes. When sending a CoA packet for a user session, the IDP MUST include verbatim any Operator-NAS-Identifier it has recorded for that session.

Additional Attributes Related to OpenRoaming Settled OpenRoaming settled defines the use of additional RADIUS attributes.

WBA-Financial-Clearing-Provider All OpenRoaming ANPs and IDPs that support the OpenRoaming settled service MUST use the WBA-Financial-Clearing-Provider vendor specific attribute to signal the identity of the provider of financial clearing services .

WBA-Data-Clearing-Provider All OpenRoaming ANPs and IDPs that support the OpenRoaming settled service MAY use the WBA-Data-Clearing-Provider vendor specific attribute to signal the identity of the provider of data clearing services .

WBA-Linear-Volume-Rate In cellular roaming, inter-operator tariff information is exchanged in the roaming agreements between operators. In OpenRoaming, as there is no direct agreement between ANPs and IDPs, the tariff information is exchanged in RADIUS messages. All OpenRoaming ANPs that support the OpenRoaming settled service MUST use the WBA-Linear-Volume-Rate vendor specific attribute to signal the charging model being offered by the ANP . An IDP that authorizes an offered charging model MUST include the agreed WBA-Linear-Volume-Rate in the Access-Accept packet.

OpenRoaming Session Mediation OpenRoaming-Settled necessarily requires end-entities, which may include ANPs, IDPs and/or their respective hub-providers, to be able to perform session mediation between RADIUS Access-Request/Access-Accept and RADIUS Accounting-Request messages. This can be performed using RADIUS attributes Acct-Session-Id (#44) and Acct-Multi-Session-Id (#50) together with Operator-Name (#126). To allow for possible non-uniqueness of Acct-Session-Id and/or Acct-Multi-Session-Id attributes between different Network Access Servers (NAS) within the same ANP, it is recommended to additionally use the attribute NAS-Identifier (#32) or NAS-IP-Address (#4) or NAS-IPv6-Address (#95) or Called-Station-Id (#30) in the matching process.

Security Considerations

Network Selection and Triggering Authentication OpenRoaming defines the use of Passpoint with Roaming Consortium Organization Identifiers. A bit-wise match between an RCOI configured in the Passpoint profile of an end-user's device and the RCOI signalled by WLAN equipment will trigger a Passpoint defined EAP-based authentication exchange. The security associated with the Passpoint RCOI information element is identical to other PLMN Id and Realm information elements, allowing an unauthorized system to configure the OpenRoaming RCOI with the aim of triggering a Passpoint authentication. Because such an unauthorized system will not have been issued with a certificate from WBA's PKI, the unauthorized system is unable to communicate with any other OpenRoaming provider. In such a scenario, after successive multiple failed authentications, the device's supplicant SHOULD add the Access Point's BSSID to a deny list to avoid future triggering of an authentication exchange with the unauthorized system.

ANP RadSec Connectivity The ANP's RadSec client connects to the IDP's RadSec server over the public Internet. Recommended best practice for firewall deployment on public Internet facing interfaces SHOULD be followed. Firewall rules SHOULD permit outbound RadSec traffic (TCP destination port 2083) and allow return traffic for the same TCP connections while denying any TCP socket initiation from outside of the ANP's network.

Dynamic Discovery of RadSec Peers Whereas the dynamic discovery mechanisms specified in permit the IDP to use their DNS SRV record to indicate a non-standard TCP port to be used in a RadSec connection, IDPs SHOULD recognize that ANP systems may only be configured to permit outbound connections on the standardized RadSec port of 2083. OpenRoaming recommends the use of DNSSEC to ensure a dynamically discovered RadSec server is authoritative for a particular realm or set of realms. Where this is not possible, e.g., when using dynamic resolution with the pub.3gppnetwork.org sub-domain, the OpenRoaming certificate policy permits the configuration of supported realm(s) in the SubjectAltName of the certificate(s) issued to the IDP. An ANP MAY decide to continue with the RadSec establishment, even if a server cannot prove it is authoritative for a realm. As the ANP's RadSec client uses a dedicated trust store corresponding to the WBA's private Certificate Authority, if DNS is hijacked by a third-party non-federation member who has not been issued a certificate under WBA's PKI, the subsequent TLS establishment will fail. In order to prevent denial of service/brute force attacks, IDPs SHOULD implement intrusion prevention functionality that monitors systems to identify TLS mutual authentication failures. Monitoring SHOULD identify source IP addresses that are causing repeated TLS authentication failures and use firewall functionality to temporarily block packets from those source IP addresses

End-User Traffic The OpenRoaming federation ensures RADIUS traffic is secured between ANP and IDP and ensures Wi-Fi traffic is protected between the end-user device and the WLAN equipment of the ANP. The ANP is therefore able to observe IP traffic to/from end-users who have performed a successful authentication with their IDP. The OpenRoaming legal framework (see ) ensures that the ANP has agreed to the OpenRoaming Privacy Policy to correctly handle the personally identifiable information collected as part of providing the ANP service. The Open-Roaming end-user terms and conditions ensure that end-users are aware that the federation does not provide a secure end-to-end service. The end-user MUST NOT rely on the encryption delivered by OpenRoaming for providing security of services accessed using the ANP's Wi-Fi network.

ANP Inspection of End-User Traffic All OpenRoaming ANPs MUST implement layer 2 traffic inspection and filtering, as specified in clause 5.1 of the specification. ANPs MUST prohibit the delivery of any packet received from an OpenRoaming device directly to another OpenRoaming end-user device. All ANPs MUST use traffic inspection and filtering to help protect OpenRoaming users from malicious activity on the Internet as well as possible malicious activity by other authenticated OpenRoaming users. ANP traffic filtering function SHOULD NOT block ports associated with Wi-Fi calling, including UDP ports 500 and 4500 used by Internet Key Exchange (IKE), Internet Security Association and Key Management Protocol (ISAKMP) and IPSec . Recommended best practice for firewall deployment on public Internet facing interfaces SHOULD be followed, including configuring the traffic inspection and filtering using information derived from reliable sources of threat intelligence.

End-User Location The OpenRoaming legal framework (see ) ensures that the IDP has agreed to the OpenRoaming Privacy Policy to correctly handle the location-based personally identifiable information collected as part of providing the IDP service. Unless the IDP has agreed a separate privacy policy with the end-user, the IDP MUST only use location information signalled by an ANP for either: Making service authorization decisions based on the location of the ANP's wireless network; or Compliance with applicable law, or law enforcement requests.

Future Enhancements WBA announced the launch of its OpenRoaming Federation in June 2020. Since then, WBA members have continued to enhance the technical framework to address new market requirements. WBA encourages those parties interested in adapting OpenRoaming to address new opportunities and use-cases to join the Alliance and help drive the definition of OpenRoaming forward.

IANA Considerations This document has no IANA actions.

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 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] This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community. This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community. This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community. 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] This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card. EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community. This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [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 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. This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community. This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community. 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] This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter. The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK] This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. This document is not an Internet Standards Track specification; it is published for informational purposes. This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap." The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK] RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute. This document updates RFCs 3580 and 4072. 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. 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 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 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 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. RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets. This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. Deutsches Forschungsnetz | German National Research and Education Network Painless Security Fondation Restena | Restena Foundation This document defines transport profiles for running RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), allowing the secure and reliable transport of RADIUS messages. RADIUS/TLS and RADIUS/DTLS are collectively referred to as RadSec. This document obsoletes RFC6614 and RFC7360, which specified experimental versions of RADIUS over TLS and DTLS. InkBridge Cisco This document defines a "reverse Change-of-Authorization (CoA)" path for RADIUS packets. A TLS connection is normally used to forward request packets from a client to a server and to send responses from the server to the client. This specification allows a server to send CoA request packets to the client in "reverse" down that connection, and for the client to send responses to the server. Without this capability, it is in general impossible for a server to send CoA packets to a Network Access Server (NAS) that is located behind a firewall or NAT. This reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. This document updates RFC8559. Cisco Systems CableLabs This document describes a syntax for the Connect-Info attribute used with the RADIUS protocol, enabling RADIUS clients to provide RADIUS servers information pertaining to a user's connection with an IEEE 802.11 wireless network.

Example OpenRoaming Signalling Flow An example signalling flow for OpenRoaming is illustrated in . In step 1, the WLAN is configured with Passpoint information and includes configured RCOIs in its beacon. The beacon can only contain 3 RCOIs and so if none of the RCOIs match a profile provisioned in the device, the device queries for the list of RCOIs supported. If the list includes an RCOI that matches a configured profile in the device, then device sends an EAPOL Start message to the authenticator. The authenticator in the AP/WLC requests the EAP-Identity of the device. The device responds with its EAP-Identity, which is a user@realm Network Access Identifier (NAI) The NAS in the WLC/AP embeds the NAI in the user-name attribute in a RADIUS Access-Request packet and forwards to the configured RadSec client. The RadSec client recovers the realm from the NAI/user-name attribute and performs a DNS-based dynamic peer discovery. The RadSec client established an mTLS authenticated TLS session with the discovered peer using certificates issued by the WBA PKI. Once TLS is established, the RadSec client forwards the Access-Request to the RadSec server. If the EAP Server is not co-located with the RadSec server, the RadSec server proxies the Access-Request to the EAP-Server. The EAP-Server continues the EAP dialogue with the EAP Supplicant in the end-user device using a Passpoint defined EAP method. Following successful authentication, the EAP-Server responds with a RADIUS Access-Accept packet containing the EAP-SUCCESS message and the keying material generated through the EAP method to secure the Wi-Fi session. The Access-Accept packet is forwarded back to the RadSec client. The RadSec client forwards the Access-Accept packet to the NAS in the AP/WLC. The AP/WLC recovers the keying material from the Access-Accept packet and forwards the EAP-SUCCESS message to the device. The keying material is used to secure the Wi-Fi interface between the end-user device and AP/WLC. The AP/WLC generates a RADIUS Accounting-Request packet with Acct-Status-Type Start which is forwarded to the RadSec client. The RadSec client forwards the Accounting-Request packet over the TLS tunnel to the RadSec server. The RadSec server can forward the Accounting-Request packet to the EAP-Server.

• 20-22. After the Wi-Fi session terminates, an Accounting-Request message with Acct-Status-Type Stop is proxied towards the RadSec Server.

| | | | | | 3) EAPOL | | | | | | Start | | | | | |---------->| | | | | | 4) EAP-ID | | | | | | Request | | | | | |<----------| | | | | | 5) EAP-ID | 6) RADIUS | | | | | Response | Access- | 7) DNS | | | |---------->| Request | Query | | | | |---------->| NAPTR,SRV,| | | | | | A/AAAA | | | | | | Records | | | | | |<--------->| | | | | | 8) mTLS | | | | | |<--------------------->| | | | | 9) RadSec | | | | | | Access-Request | | | | |---------------------->| | | | | | | 10) RADIUS| | | | | | Access- | | | | | | Request | | | | | |---------->| | | 11) EAP Dialogue | | |<--------------------------------------------------------->| | | | | | 12) RADIUS| | | | | | Access- | | | 14) RADIUS| | | Accept | | | Access- | | | (EAP- | | | Accept | 13) RadSec Access- | SUCCESS) | | | (EAP- | Accept (EAP-SUCCESS) |<----------| | 15) EAP- | SUCCESS) |<----------------------| | | SUCCESS |<----------| | | | |<----------| | | | | +---------------+ | | | | | 16) Secured | | | | | | OpenRoaming 17) RADIUS| | | | | Service Accounting| | | | | Request | | | 19) RADIUS| | (Start) | 18) RadSec Accounting | Accounting| | |-------->| -Request (Start) | Request | | | |---------------------->| (Start) | | | | | |---------->| +---------------+ | | | | | | 20) RADIUS| | | | | | Accounting| | | | | | Request | | | 22) RADIUS| | | (Stop) | 21) RadSec Accounting | Accounting| | |---------->| -Request (Stop) | Request | | | |---------------------->| (Stop) | | | | | |---------->| +------+ +------+ +------+ +------+ +------+ +------+ |Device| |Wi-Fi | |RadSec| | DNS | |RadSec| | EAP | | | |AP/WLC| |Client| | | |Server| |Server| +------+ +------+ +------+ +------+ +------+ +------+ ]]>

Example OpenRoaming RCOI Usage This Annex illustrates the use of OpenRoaming RCOIs to enforce different policies in the OpenRoaming federation, ensuring that when there is a policy mismatch between the end-user device and access network, that the end-user device will avoid triggering an authentication exchange that would subsequently have to be rejected because of policy enforcement decisions.

OpenRoaming RCOI Based Policy for Supporting QoS Tiers illustrates the use of OpenRoaming RCOIs for supporting the standard (bronze) and silver QoS tiers across the federation. The figure shows two different devices: Device 1 has been provisioned by its IDP to require the basic bronze QoS policy. Device 2 has been provisioned by its IDP to require the silver tier of QoS handling. The figure also shows illustrates the RCOI configuration of two ANP Access Networks: ANP#1 is configured to support the silver tier of QoS handling corresponding to the silver RCOI. Because the network requirements associated with the silver tier are a superset of the bronze QoS tier, the ANP also configures the bronze RCOI on its Wi-Fi access network. ANP#2 is only configured to support the standard (bronze) QoS tier and as such only configures the RCOI corresponding to the bronze QoS tier on its Wi-Fi access network. The figure shows how normal Passpoint RCOI matching rules can be used to ensure that devices only trigger authentication with ANP access networks which support the required QoS tier according to the device's policy.

OpenRoaming RCOI Based Policy for Supporting Identity Type Policies illustrates the use of OpenRoaming RCOIs for supporting different identity type policies across the federation. The figure shows two different devices: Device#1 has been provisioned by an IDP corresponding to a service provider. It provisions the device's Passpoint profile with the RCOI policy identifying the service provider ID-type policy as well as the "any ID-type" RCOI policy. Device 2 has been provisioned by a IDP corresponding to a hospitality provider. It provisions the device's Passpoint profile with the RCOI policy identifying the hospitality ID-type policy as well as the "any ID-type" RCOI policy. The figure also shows the RCOI configuration of three different ANP Access Networks: ANP#1 only supports access using service provider type-IDs and so has configured the service provider ID-type policy RCOI. ANP#2 supports access from all identity types and so has configured the any ID-type policy RCOI. ANP#3 only supports access using hospitality type IDs and so has configured the hospitality ID-type policy RCOI. The figure shows how normal Passpoint RCOI matching rules can be used to ensure that devices only trigger authentication with ANP access networks which support the required identity types according to the ANP's policy.

OpenRoaming RCOI Based Policy for Supporting Different Identity Proofing Policies illustrates the use of OpenRoaming RCOIs for supporting different identity proofing policies across the federation. The figure shows two different devices: Device 1 has been provisioned by an IDP that uses enhanced identity proofing controls that meet the enhanced OpenRoaming requirements, equivalent to LoA 3 in . Because the enhanced identity proofing requirements are a superset of the requirements of the baseline identity proofing policy, the IDP also configures the use of the RCOI with baseline identity proofing. Device 2 has been provisioned by an IDP that uses identity proofing with controls that meet the baseline OpenRoaming requirements. The figure also shows the RCOI configuration of two ANP Access Networks: ANP#1 is operated in a geography where regulations require support of enhanced identity proofing. ANP#2 is operated in a geography where regulations permit support of authentications with identities managed using the OpenRoaming baseline identity proofing requirements. The figure shows how normal Passpoint RCOI matching rules can be used to ensure that devices only trigger authentication with ANP access networks which support the required identity proofing according to the ANP's policy.

OpenRoaming Legal Framework

Seamless Experience In order for OpenRoaming to avoid the need for end-users to be presented with and accept legal terms and conditions covering their use of the Wi-Fi hotspot service, there needs to be a legal framework in place.

OpenRoaming Organization The federation is based on a legal framework that comprises a set of policies, templated agreements and immutable terms as agreed to by the WBA and its membership. The framework defines a hierarchy of roles, responsibilities and relationships that are designed to enable the federation to scale to millions of Wi-Fi access networks. shows the relationships between WBA, OpenRoaming Brokers, who are members of the WBA that have agreed terms with WBA to perform the OpenRoaming broker role and the OpenRoaming providers. OpenRoaming brokers agree terms with OpenRoaming Providers that can act as Access Network Providers (ANPs) and/or Identity Providers (IDPs). OpenRoaming providers do not have to be members of the WBA to provide OpenRoaming services. Finally, OpenRoaming IDPs agree terms with OpenRoaming end-users who then benefit from seamless authentication onto the Wi-Fi networks deployed by the different OpenRoaming ANPs.

|OpenRoaming| |Broker | |Broker | +-----------+ +-----------+ /|\ /|\ /|\ /|\ | | | | Agrees terms with Agrees terms with | | | | +-----+ +-----+ +-----+ +-----+ | | | | \|/ \|/ \|/ \|/ +-----------+ +-----------+ +-----------+ +-----------+ |OpenRoaming| |OpenRoaming| |OpenRoaming| |OpenRoaming| |Access | |Identity | |Identity | |Access | |Network | |Provider | |Provider | |Network | |Provider | | | | | |Provider | +-----------+ +-----------+ +-----------+ +-----------+ /|\ /|\ /|\ /|\ | | | | Agrees terms with Agrees terms with | | | | +-------------+ | | +------------+ | | | | \|/ \|/ \|/ \|/ +-----------+ +-----------+ +-----------+ +-----------+ |OpenRoaming| |OpenRoaming| |OpenRoaming| |OpenRoaming| |End-User | |End-User | |End-User | |End-User | +-----------+ +-----------+ +-----------+ +-----------+ ]]>

OpenRoaming Legal Terms In OpenRoaming there is no direct agreement between individual ANPs and individual IDPs or between end-users and ANPs. As a consequence, OpenRoaming brokers agree to use certain federation-specific terms in their agreements with OpenRoaming providers. This arrangement ensures that all ANPs agree to abide by the OpenRoaming privacy policy and all end-users agree to abide by the OpenRoaming end-user Terms and Conditions .

ANP Performance Data ANPs MAY voluntarily share performance data with IDPs related to the performance of ANP's wireless network used by the IDP's OpenRoaming end-users. IDPs that do not separately agree to terms with ANP governing use of performance data MUST solely process collected performance data for the purposes of provision of the service, including making service authorization decisions and network troubleshooting. These IDPs MUST NOT disclose such performance data to any third party except as necessary for direct network troubleshooting with the originating ANP.

Service Abuse If an ANP detects service abuse by an end-user in contravention of the end-user Terms and Conditions, the ANP SHOULD record logs relevant to the abuse and use the email address embedded in the Subject Alternative Name (SAN) attribute in IDP's issued end-entity certificate to contact the abuser's IDP, indicating the nature of the abuse together with any relevant logs. The immutable terms of OpenRoaming REQUIRE IDPs to make reasonable efforts to address the service abuse experienced by the ANP, which may include the withdrawal of the OpenRoaming service from the identified abusive end-user.

OpenRoaming Troubleshooting The immutable terms included in the OpenRoaming templated agreements require OpenRoaming providers to make reasonable efforts to support troubleshooting procedures, including monitoring email addresses shared for troubleshooting purposes. OpenRoaming defines the following severity levels: Severity 1: OpenRoaming service is not available, Severity 2: OpenRoaming service is severely impacted, Severity 3: OpenRoaming service is partially degraded, and Severity 4: Informational. Prior to escalating any issue with a third party, the initiating provider should conduct an initial assessment, logging any troubleshooting steps and recording all logs relevant to the issue. The initiating provider should designate a contact for handling troubleshooting and share such with the third-party provider contact identified via the respective WBA PKI certificate, together with details of the issue, including its severity.

Issue Response The third-party shall respond to all escalations raised by initiating providers. The recommended maximum timeframes for the initial email response for issue response associated with the OpenRoaming Settled Service are as follows: Severity 1: Email response within 2 days. Severity 2: Email response within 4 days. Severity 3: Email response within 8 days. Severity 4: Email response within 28 days. This does not preclude a provider unilaterally agreeing to shorter timeframes for responding to initial issues. The initiating provider and the third-party shall use reasonable efforts to try and identify any issues and remediate any problems. Both providers should record affected systems and attempted resolutions.

Issue Escalation If the issue cannot be resolved to the acceptance of both providers within an acceptable timeframe, the provider may escalate the issue to WBA. The recommended maximum timeframes before escalations associated with OpenRoaming Settled Service are escalated to WBA as follows: Severity 1: Escalate after 4 working-days of issue non-resolution. Severity 2: Escalate after 8 working-days of issue non-resolution. Severity 3: Escalate after 28 working-days of issue non-resolution. Severity 4: Escalation is not applicable. This does not preclude both access network and identity providers bilaterally agreeing to shorter timeframes for handling issue escalation. Escalation includes sharing all logs and correspondence regarding the issue and attempts at resolution.

Breach of Contract Where it can be determined that an End-Entity is in breach of their contract terms as defined in the OpenRoaming legal framework, WBA reserves the right to cancel the End-Entity's OpenRoaming enrolment and revoke any WBA issued certificates.

Changelog 01 - added details of WBA-Custom-SLA for OpenRoaming ANP networks that signal using that they operate on a vehicular platform. Added clarifications regarding use of direct and indirect names in certificate validation. 02 - added details of OpenRoaming protection of end-user privacy, including WRIX recommendations on use of correlation identifiers in RADIUS Access-Accept packet that may unintentionally weaken end-user privacy. 03 - updated DNSsec reference. Added section on interworking with other federations. 04 - updated PKI Policy OID to reflect new certificate chain. Added IDP availability requirements. Added session-timeout requirements. Added new onboarding capabilities for short lived credentials. Added text concerning OpenRoaming Privacy Policy and restrictions on location usage. 05 - added new section on use of Reply-Message, added new text on troubleshooting, clarified RADIUS accounting handling, clarified CUI usage in Access-Accept, clarified use of EAP types. 06 - corrected ePDG FQDN. Added missing enhanced Reply-Message for cause-code = 45. Added new text regarding recommended best practice for firewall deployment on public Internet facing interfaces should be followed for ANP RADSEC connections and for protecting end-users. 07 - added details of service abuse handling. Added further details of RADIUS attributes. Added rationale for busy hour sustained throughput values. Introduced requirements on minimum speeds for OpenRoaming bronze and silver tiers. Corrected WBAID ABNF by adding in permitted special characters. 08 - added clarification on the use of "aaa+auth" to identify a RadSec server that supports both RADIUS authentication and accounting. Added requirements for reverse CoA and associated RadSec connection management. Added support for enhanced RADIUS connect-info for connection instrumentation and authorization.

Acknowledgements The authors would like to thank all the members of the WBA's OpenRoaming Workgroup who help define the OpenRoaming specifications.