Roam Decentralized OpenRoaming WiFi
3.3 Roam WiFi
Roam WiFi is enabled by three components: a RADIUS and Access Point Controller which supports DID/VC-based log-ins; SDKs that allow for mobile devices to login to OpenRoaming WiFi with DID/VC, and that give these devices access to the on-chain data; and an OpenRoaming- supporting backend including SDKs for any ID providers becoming OpenRoaming ID providers via Roam.
3.3.1 DID/VC log-in
3.3.1.1 RADIUS Integration
In order to allow users to login to WiFi with DID/VC, the RADIUS system must support these standards, and the methods it uses must work with the user devices as well. The majority of the Roam innovation is related to the authentication process.
On the user device side and using iPhone as an example, developers can configure the various EAP protocols for Apple devices enrolled in a mobile device management (MDM) solution. MDM solutions can support the following 802.1x authentication methods for WPA Enterprise and WPA2 Enterprise networks: TLS, TTLS (MSCHAPv2), EAP-FAST, EAP-SIM, PEAP (EAP- MSCHAPv2, the most common form of PEAP), PEAP (EAP-GTC, less common and created by Cisco), EAP-AKA (requires no additional configuration). As mentioned in section 1.2.1.3, EAP- TLS, EAP-TTLS, and EAP-PEAP are three possible choices for enterprise WiFi, and all of them are supported by the existing RADIUS protocol.
Under EAP-TLS, both the client and the server must be assigned a digital certificate signed by a Certificate Authority (CA) that they both trust. With a client-side certificate, a compromised password is not enough to break into EAP-TLS-enabled systems because the intruder still needs to have the client-side certificate. Although EAP-TLS has a higher security standard, it is a nightmare to manage both sides of the certificate, which makes it impractical for a WiFi login system. As a result, EAP-TTLS and EAP-PEAP are more common for a WiFi RADIUS setup.
Both EAP-TTLS and EAP-PEAP make use of the Transport Layer Security (TLS) protocol to provide integrity and confidentiality protection. In EAP-TTLS/PEAP, the server mainly uses two phases, i.e., the TLS handshake and TLS tunnel phase, to establish a secure connection to the client. These protocols only require a server certificate, while the client authentication is optional per the RFC standard. During the TLS handshake phase, the TTLS server authenticates the client using standard TLS procedures. In the tunnel phase, the client authenticates the server using an arbitrary protocol within the encrypted tunnel. The protocol can be EAP, PAP, MS-CHAP, and so on. On EAP-TTLS, after the server is securely authenticated to the client via its CA certificate and optionally, the client to the server, the server can then use the established secure connection ("tunnel") to authenticate the client. EAP-PEAP is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication. It uses server-side public key certificates to authenticate the server,then creates an encrypted TLS tunnel between the client and the authentication server. PEAP is an SSL wrapper around EAP,while TTLS is an SSL wrap.
EAP-PEAP is especially useful as a mechanism to augment the security of legacy EAP methods. The difference between it and EAP-TTLS is that instead of encapsulating EAP messages within TLS, the TLS payload of EAP-TTLS messages consists of a sequence of attributes. By including a RADIUS EAP-Message attribute in the payload, EAP-TTLS can be made to provide the same functionality as EAP-PEAP. If, however, a RADIUS Password or CHAP-Password attribute is encapsulated, EAP-TTLS can protect the legacy authentication mechanisms of RADIUS.
The advantage of this becomes apparent if the EAP-TTLS server is used as a proxy to mediate between an access point and a legacy home RADIUS server. When the EAP-TTLS server forwards RADIUS messages to the home RADIUS server, it encapsulates the attributes protected by EAP- TTLS and inserts them directly into the forwarded message. The EAP-TTLS messages are not themselves forwarded to the home RADIUS server. Thus the legacy authentication mechanisms supported by existing RADIUS servers in the infrastructure can be protected for transmission over wireless LANs. EAP-TTLS is also the most common approach to secure authentication and communication used for WiFi.
Let’s examine a typical RADIUS-based login process for Roam WiFi, where EAPoL Protocol = Extensible Authentication Protocol over LAN:
If a login process does not rely on a username and password, the following changes shall be made:
In the handshake phase, the TLS tunnel will be established based on a certificate derived from the same private key as the DID owner. In this situation, the following steps are required:
a) First, the user, AP (RADIUS client), and RADIUS need to register their DIDs in the on- chain registry. The VC issuer will maintain VC status in on-chain registries as well. This will replace the step 1 in the standard WiFi login process.
b) To sign the certificate, the RADIUS will use the same private key as either the root CA, or the intermediate CA (if it is in the chain of trust within a large system).
c) Once a device encounters an access point (authenticator), communication will be established with the RADIUS via IEEE802.1x.
d) The AP will send an ID request, and the user provides a bogus username, which the AP adds with its DID, and sends to the RADIUS server.
e) The RADIUS server sends EAP requests with it DID, and the user provides their DID with a Hello message.
f) The RADIUS server responds to the user with its certificate, which the user will validate.
g) The user will respond and the RADIUS server will move to the next step and ask for a real username. After this, the tunnel is established.
In the tunneling phase, the main difference between Roam WiFi and regular WiFi is that the RADIUS does not use the username/password information as in the normal case. Instead, the RADIUS server will try to validate the VP of the user to check whether the VC holder who issued the VP has the right to log-in. The tunneling phase of the Roam WiFi login process is as follows:
a)The user sends their DID including a Roam realm to the RADIUS server.
b)The RADIUS server sends a request with a MS-CHAP-V2 challenge. The challenge is a random number per MS-CHAP-V2 protocol.
c)The user responds to the challenge by sending a VP back to the RADIUS server, in which the nonce is set by the challenged number defined in the last step. Due to the fact that MS-CHAP-V2 has a fixed attribute specification, the VP could not be incorporated unless it has been put into the vendor-specific field per RFC 2865 section 5.26.
d)Once the RADIUS server receives the VP, it will from the blockchain validate its content (checking that it is ok to login) and the status of the VC behind it.
e) The RADIUS server will acknowledge the user.
f) Encrypted data communication will start.
g) The RADIUS server will return the VP of the RADIUS back to the user, who will acknowledge the VP’s reception.
The key process is to attach the VP to the CHAP challenge. Note that the above process implemented with EAP-TTLS has a weakness: in the RADIUS protocol associated with EAP- TTLS, the vendor-specific information is not originally designed as a judgment factor but rather as an optional factor. Though Roam can manage this weakness with an update to RADIUS, it is still better to use EAP-TEAP instead. Tunnel Extensible Authentication Protocol (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, data in the form of type, length, and value (TLV) objects are used to send further authentication-related data between the EAP client and the EAP authentication server. The main benefit of engaging TEAP rather than TTLS is that with TEAP, the VP which is associated with the vendor specific information could be included as a mandatory attribute of the challenge. Due to this situation, any devices which support EAP-TEAP - like Windows 10 and Windows 11 devices - will natively support Roam protocol, and a mobile app will not be needed purely for the WiFi log-in process.
The EAP-TEAP implementation process for WiFi logins is as follows:
In comparison to the standard process as shown above, the following changes have been made to EAP-TEAP by Roam protocol to provide a more native implementation of DID / VC for the WiFi authentication process:
a) In the (Authority-ID TLV) sent by the RADIUS server to the supplicant (user), the RADIUS DID is included in the ID session following the format below:
b) The user authentication process is based on Basic-Password-Auth-Req. Similar to the login implementation of EAP-TTLS, the username is the user’s DID and the Prompt is the user’s VP. The RADIUS server verifies the user’s identity via their VP. The Basic Password- Auth-Req TLV is as follows:
The above discussion explains the difference in the authentication processes between Roam and regular Passpoint / OpenRoaming WiFi. In terms of authorization and accounting, the process will be similar between Roam and other Passpoint / OpenRoaming WiFi networks as described in Section 1.2.2.3 (Onboarding Policy Control).
3.3.1.2 Distributed RADIUS Service
To support Roam WiFi, a distributed RADIUS will be operated by the Roam foundation initially. Access points could search the RADIUS and connect to a usable RADIUS server automatically. The status of the credentials of these distributed RADIUS servers will be maintained by the blockchain. Load balancing will be implemented by allowing miners to randomly select different RADIUS /AAA servers. Later-on, elected community representatives will participate in these services by staking a certain number of tokens. In return, they will be awarded with further tokens since they must defend the network against malicious attacks and ensure its smooth operation. The distributed RADIUS could be further developed based on FreeRADIUS, using one of its modules for the updated EAP-TTLS implementation as well as the EAP-TEAP implementation. Please note that the RADIUS client will reside in each miner.
The proposed log-in process requires users to hold a valid VP. As a result, trustworthy VC issuers are required, and the Roam foundation maintains a list of their public keys. When a device interacts with the access points, both parties will verify each other’s DID status on-chain. If both are valid, the exchange of VPs will happen as well. During this process, the VC information included in either party’s VP will be examined, including who the issuer is, whether the issuer is trustworthy per the on-chain list, and whether the VC has been altered illegally. This will be carried out by validating the signature and the consistency between the signature and the public key information inside the VC. If the VC is ok, future validation will be performed with the VP, including validation of whether its associated DID is consistent with the DID used for the authentication process.
One more step will be performed when a user logs into the Roam network. Their device will submit connection information like QoS status to the on-chain smart contract, and a copy of this info will be sent to the Roam backend as well. At the same time, Roam access points will submit the information on the connected DIDsto Roam’s backend and on-chain smart contracts. This DID info will be the source of the network’s “3W” data.
3.3.1.3 DID and VC Integration on Mobile Devices
DID, VC and Wallet
As introduced in Chapter 3.2.2, the DID has emerged as a promising solution for providing secure and privacy-preserving digital identity, while VCs are digital credentials that enable individuals to prove their identity, qualifications, or other attributes without revealing unnecessary personal information. Roam is leveraging VCs to enable secure WPA2/3-EAP authentication for its OpenRoaming Network. To enable access to these services, a public key Infrastructure (PKI) is required to distribute and manage VCs. In the initial development phase, Roam will deploy a PKI and combine it with Decentralized Identifiers (DIDs).
Roam’s DID will be derived as follows: an Elliptic Curve Digital Signature Algorithm generates a private key, then Keccak-256 is used to hash and produce an Etherem compatible Account Address which joins with the DID scheme and method prefixes. Other organizations could deploy their own PKIs, and the VCs which they generate could be recognized by Roam protocol as long as they support the WBA OpenRoaming framework.
DIDs provide a unique and decentralized way of identifying users, enabling them to control their identity and associated data. When users want to access Roam services for the first time without any VC, they could choose to accept a VC signed by the Roam Foundation. If they accept, a VC with the users DID will be issued to them instead of a standard x509 user certificate. The VC will contain their identity information, which can be verified using a decentralized ledger. The VC can be saved in a specialized credential saving area of the users’ Wallet, along with identity documents issued by other organizations. Once their VC has been issued, users can produce a one-time Verifiable Presentation (VP) by adding their holder information to the VC whenever they need to identify themselves. It is also possible for users to choose what information they want to present using their VP, preserving privacy. This VP could be used for the WiFi login process as described in Chapter 3.3.1.1.
VCs for Roam network access could be issued by any organizations which incorporate the W3C’s DID and Verifiable Credential protocols. Such organizations could become VC issuers and maintain the status of the VCs which they issue on the blockchain. If a given WiFi node is an RCOI-free node, the VC holders from any of these organizations could log-in at this node. If a specific user-login management scheme is defined in the relevant nodes, only users whose VC includes the credentials satisfying the scheme’s requirements can log in at these nodes. This approach enables users to control their identity and associated data, providing increased privacy and security. VCs are designed to be interoperable and can be used across different services and organizations, making them a promising solution for a range of identity use cases.
Mobile Phones
The implementation of Roam using mobile phones will happen in different phases, as it takes time for mobile phone manufacturers to catch up. In the meantime, the Roam app or any app which integrates Roam SDKs is required to interact with the OpenRoaming access points.
The Roam mobile app provides users with a Crypto Wallet, DID, Roam Foundation-signed VC, and other OpenRoaming credentials. Users connecting to Roam network for the first time via the app can either use their emails or social media accounts; or they can choose to create a new Wallet or import their existing one using their private Key. The App generates a DID by using the user's public key as input, which key remains secure and undisclosed due to the use of a hashing algorithm. The DID is then added to the Decentralized Ledger and used to request a VC from the Roam Foundation. Using the VC, the App automatically provisions an OpenRoaming Profile for users with a compatible device. The VC is securely stored in the Wallet and can be used to verify users' identities when interacting with the Roam access points.
When a mobile device interacts with the access points, the mobile app will handle the further interactions with Roam’s distributed RADIUS as defined in Section 3.3.1.2. Such interactions will be recorded and submitted to the Roam backend and on-chain smart contract by both the mobile app and the access point. This will result in the generation of DID-based Who, When and Where (“3W”) data.
Windows / Linux
It is fairly straightforward to integrate DID / VC with Windows platforms via Windows Native APIs, which support the proposed implementations of both EAP-TTLS and EAP-TEAP.
With Linux, the integration development uses an open-source WPA_Supplicant module. As for EAP-TEAP, it is developed based on the existing EAP-Flexible Authentication via Secure Tunneling (FAST) module, for which a client side authentication process will be released. VP authentication will be added to the Basic-Password-Auth process per EAP-TEAP as well. As for EAP-TTLS, it will update the existing FAST module.
The Roam access point also offers an effortless way for users to access the Roam OpenRoaming Network from their desktops or laptops. By default, the access point broadcasts an Onboarding WiFi signal in addition to the OpenRoaming WiFi signal. Users can easily connect to the Onboarding WiFi and access a Portal where a dynamically generated QR code can be scanned using the Roam Phone App. Once it scans this code, the computer will download and provision an OpenRoaming Profile that is compatible with the user's desktop or laptop system if the App holds a valid VC. This enables users to enjoy seamless access to the OpenRoaming Network without any manual configuration.
3.3.2 WiFi Hardware
3.3.2.1 Enterprise WiFi Devices
The typical setup of an enterprise WiFi network includes a wireless access controller (AC) which manages multiple wireless access points. An access point is the device that allows multiple wireless devices to connect with each other via a single or multiple wireless networks. An access point can also be used to extend a wired network to wireless devices. In enterprise WiFi, the network intelligence stays with the AC, which could be a dedicated server or a server in the cloud. All APs are configured by the AC. In comparison to regular WiFi, this approach provides services that can lower the price of deployment, ease the management process, and provide several layers of security.
The Roam network Gateway contains a software-based access controller (AC) that can push configurations using the Control and Provisioning of Wireless Access Points (CAPWAP) protocol.
As a result, any standard market-available access points (AP) that support OpenRoaming and CAPWAP protocol can be adopted and managed by the Roam AC, enabling users to easily extend their network.
Additionally, users have the option to add Roam APs to the network, providing a more consistent experience. Compatible APs can be connected to the Roam Gateway via its LAN port or through a switch, allowing them to join the Gateway's network and broadcast the OpenRoaming and/or Free WiFi signal.
Oftentimes, these APs are powered by Power-Over-Ethernet cables, and a POE switch will be included in the hardware list. A wired gateway or modem / router is commonly used to connect the WiFi network to the internet.
3.3.2.2 Roam Mining Device
The Roam mining device is the device which hosts the RADIUS client. It could be a wired gateway or modem / router, and can be configured with a DID and VC issued from the Roam Foundation. The controlling private key will be stored in the device locally inside the trustzone or a TPM chip. This key is not accessible by anyone else, including the Roam Foundation, ensuring that the device owners have total control over their miners.
Since the Roam mining device is an essential part of the Roam ecosystem, a series of checks will be performed before issuing a VC to the device, protecting the network’s integrity. The Roam mining device could then present the issued VC to prove its own authenticity when users try to validate the Roam OpenRoaming Network.
Roam mining devices could also function as edge computing units capable of providing wireless access, storage, and computing functions. For mining device provisioning, Roam foundation will certify qualified third party units and grant the relevant manufacturing licenses to their certified vendors.
3.3.2.3 On-Chain Registry
On-chain registries will be used to record both DID and VC status information.
DID registry
As for the DID registry, the metadata including the DID itself, DID public key information, and DID attributes will be registered. The DID document will not be registered, and the holder will generate it when needed. The DID format will be:
did:Roam:public key of the controller#self-defined name no more than 256 bytes
The attributes of the DID will be saved in the event structure:
VC registry
In terms of the VC registry, the issuer is defined as:
‘Key’ is the name of the VC in a url format, which could be associated with certificate numbers like: "https://Roam.io/test_certificates/100". The value attribute will be the issuer’s DID information.
VC information includes expiry time, credential image, revoke mechanism, claims, etc. Similar to the DID, Roam uses the following event structure to store its VC operations:
The Implementation of Nonce
Everytime a smart contract is called, the requester / DID holder shall sign the request with their DID’s private key. The smart contract then requests the usage of nonce to prevent a relay attack. The requestor / DID holder will check the nonce value of the smart contract prior to the call request. Then, he / she will sign it with the predefined method per smart contract. When the signature has been successfully validated once, the nonce value will increase automatically.
3.3.2.4 Overall Discovery, Authentication and Authorization process
The above two sections explained the overall log-in process for a Roam user roaming into a Roam- built network. But what happens if a Roam user roams into another WBA roaming partner’s network (which is built in the traditional way), or vice versa: if a user with a centralized ID but an OpenRoaming profile roams into the Roam network?
In cases where the Roam OpenRoaming service is not available, users can still connect to another WBA member's OpenRoaming Network (access network) to enjoy WiFi network services. The overall login process is like accessing a Roam-built network. Once an identity request is made by the access point, the user device will respond with a bogus ID like xxx@Roam.network. The access network will be able to recognize this Roam realm and confirm that a RADIUS server is available by checking the Name Authority Pointer (NAPTR) records. If it has been configured per WBA framework, the IP address of the RADIUS server could be obtained via DNS Service Record (SRV), and the RADIUS request could be forwarded via a proxy RADIUS. The proxy server could then redirect the incoming request, preferably including the accounting information and the user device’s VC/VP, to a Roam RADIUS server. Using the accounting information, the Roam RADIUS server will allow users to access WiFi networks which are not RCOI-Free. Roam RADIUS will then look up the VC/VP record in the decentralized ledger and validate this information before sending a response to the access network RADIUS server based on the result (of the validation). Authorized users can then roam in the available WiFi network. The communication between the access network RADIUS and Roam RADIUS will use EAP-TLS, with the tunnel being encrypted by a WBA-issued certificate. Both the access network RADIUS and the Roam RADIUS shall have these certificates as required by EAP-TLS. This seamless process ensures that users can enjoy a secure and hassle-free browsing experience, regardless of the network they are connected to.
When a user from another network roams into the Roam network, a similar process will happen. The only difference is that the Roam RADIUS will serve as the access network RADIUS, and will handle the legacy username/password-based login process. Roam ensures that the accounting information will be forwarded to the roaming partners’ RADIUS as well. Roam compatible WiFi APs and gateways typically offer WiFi services under their own SSIDs. The above process won’t be affected.
3.3.3 Network Privacy Protection and Regulatory Requirements
The core value of the Roam network is the global OpenRoaming capability and the 3W data generated by these networks. As it creates a global public network, OpenRoaming has to balance the privacy and regulatory requirements in different countries.
The DID is an essentially anonymous identifier as it is an ID that’s self-declared by its user/holder. Roam “3W” data represents users via their DIDs, so it won’t infringe on people’s privacy. However, 3W does provide great value to businesses which want to utilize such information, as most of them do not care about the real identity of their WiFi users.
During the WiFi login process, verifiable credentials are the key elements which are typically issued by verifiable credential issuers. Based on the regulatory requirements of the given jurisdiction, a Know Your Customer (KYC) process could be performed before on-boarding businesses as VC issuers for Roam protocol. In the jurisdictions where a real (non-anonymous) identity is required for internet browsing, the VC issuer will be required to maintain the relationship between the user’s real-world identity and the verifiable credentials issued to them. It is still the users themselves who link their DIDs with their own VCs. In the Roam network, these authentication services allow users to roam based on the VP generated by the VC, while the users are identified by the associated DIDs to maintain anonymity. When a regulatory body needs to investigate the network’s activities, it will be able to reach the relevant VC issuer(s) and obtain the necessary information. The Roam network won’t maintain such records.
3.3.4 Roam Applications
A series of applications are needed to facilitate the adoption of Roam. These include:
A network host backend which supports WiFi management and data analytics at Roam network locations.
An application marketplace. Common apps in the marketplace include crypto payment gateways, check-in-to earn apps, etc.
A point-redemption rewards system which allows Roam points to interface with other token reward systems.
A staking system which allows users who hold Roam tokens to generate more yield.
An NFT-based cloud mining system which allows users who do not own a hosting site to deploy a miner in such a site via the Roam foundation, and receive all of that miner's rewards.