Skip to content
draft networking v0.2.0 eduroam Created 2026-08-05 · Updated 2026-08-05

eduroam — RADIUS Service on AWS ECS

  • Product: eduroam
  • Family: Authentication

Objective

Move ASU's eduroam RADIUS service off the on-premises Cisco ISE deployment onto a containerized FreeRADIUS service in AWS, so that eduroam is operated as infrastructure-as-code with the same review, deployment, and observability discipline as the rest of our platform, and so that ISE can be decommissioned once internal network access control has moved to Arista AGNI. Along the way, bring ASU's eduroam client trust configuration back into compliance with eduroam policy.

Context

eduroam RADIUS today runs on Cisco ISE hosted on on-premises Nutanix. Internal network access control is moving to Arista AGNI, which leaves eduroam as the remaining workload on ISE. Continuing to operate an ISE cluster for a single service carries the full cost of the appliance lifecycle — licensing, patching, and Nutanix capacity — for one function.

eduroam assigns each member institution two independent roles, and ASU operates both:

  • Identity Provider (IdP) — ASU authenticates ASU users when they associate to eduroam at another institution. The visited institution proxies the request up to the US top-level RADIUS servers (TLRS), which forward it to ASU's registered RADIUS address. ASU terminates EAP and validates the credential. This is inbound traffic and it is the harder half: it owns EAP termination, the server certificate, and the identity-store integration.
  • Service Provider (SP) — ASU hosts visitors from other institutions on the ASU eduroam SSID. ASU's RADIUS proxies requests for foreign realms outbound to TLRS, which routes them to the user's home institution. ASU relays but never sees the credential.

Internet2 is the US national roaming operator; visitor authentications proxy through tlrs1.eduroam.us and tlrs2.eduroam.us, and each TLRS communicates independently with every RADIUS IP registered for the site in Federation Manager. FreeRADIUS 3 stable is the implementation recommended by the eduroam consortium, which publishes reference SP and IdP configurations.

eduroam Protocol Requirements

RFC 7593 states the eduroam requirements in RFC 2119 language, and the eduroam policy follows the same convention. The requirements split cleanly by role, which is what makes phasing viable.

Mandatory:

Requirement Role
IEEE 802.1X as the port-based access control framework SP
EAP for credential transport, RADIUS as the trust fabric both
Broadcast SSID eduroam; eduroam-* only where it collides with another SP SP
WPA2 with AES on 802.11 networks SP
Outer identity is a valid NAI carrying a realm — user@realm or @realm (RFC 7542) IdP
EAP methods must provide mutual authentication IdP
Access requests proxied transparently regardless of the EAP method they carry SP
The EAP server's CA certificate and server name published so clients can validate them IdP
A Chargeable-User-Identity request must carry Operator-Name (RFC 4372) SP

Recommended, and treated as requirements here because each prevents a known failure or abuse mode: anonymous outer identities; sending Operator-Name; Status-Server (RFC 5997) for peer liveness detection; not forwarding accounting; disabling proxying within the EAP tunnel data so a crafted outer/inner realm mismatch cannot launder a user's origin; and provisioning clients through eduroam CAT rather than documenting manual configuration.

Optional and backwards compatible: RadSec (RFC 6614) with NAPTR dynamic discovery, which RFC 7593 §4 describes as the successor trust fabric, upgradeable one RADIUS link at a time.

The transparent-proxy requirement is why the phasing works. As an SP, ASU must relay every EAP method untouched and never terminate a visitor's EAP conversation, so the identity-store and EAP-method decisions belong entirely to the IdP role. The SP work is independent of them.

Current Configuration

Established from the eduroam overview KB, the Android configuration KB, the Apple configuration KB, and inspection of the published Apple configuration profile.

Setting Value
EAP method PEAP (EAP type 25)
Inner method MSCHAPv2
Outer identity anonymous@asu.edu
Inner identity ASURITE@asu.edu
Credential ASURITE password
Realm asu.edu
RADIUS server name asu-nac.asu.edu, asu-nac26.asu.edu

The ISE estate is visible in the profile's certificate SANs: admin, monitoring, and up to ten policy service nodes each across dc1-nac, dc2-nac, dc2-nac2, and dc3-nac2, plus the nac-mydevice and nac-sponsor portals. The newer certificate narrows to dc1-nac and dc2-nac only, suggesting consolidation has already occurred.

Three defects in the client trust configuration are load-bearing for this plan.

The server name is not validated. The Apple profile's EAPClientConfiguration contains AcceptEAPTypes, OuterIdentity, PayloadCertificateAnchorUUID, and TLSAllowTrustExceptions: false. TLSTrustedServerNames is absent. The anchor list includes four public CA certificates — AAA Certificate Services, USERTrust RSA Certification Authority as both root and intermediate, InCommon RSA Server CA, and InCommon RSA Server CA 2. Anchors are alternatives rather than requirements, so any server certificate issued under InCommon or USERTrust validates as ASU's RADIUS server. InCommon issues to most US research universities. Because TLSAllowTrustExceptions is false, the user is never prompted; an impostor is accepted silently.

Android is instructed to skip validation entirely. Step 7 of the Android KB reads "Skip CA certificate (this will be loaded from the ASU eduroam radius server first time you connect)." Nothing is loaded or pinned; validation is disabled permanently. eduroam Operations states that instructing users to disable server identity validation "is a breach of the eduroam policy". Separately, those instructions have not been followable since Android 11 removed the "Do not validate" option in September 2020, and Android is offered no configuration profile.

The published profile is stale and its expiry is self-inflicted. Both ASU leaf certificates in the profile expired — January 2024 and January 2025 — as did the InCommon RSA Server CA intermediate in October 2024. The profile is named v2024 and the KB states refreshes ship each December to January. Connectivity survives regardless, because the live server certificate chains to the still-valid public CA anchors. The annual renewal therefore has no functional forcing signal, which is why two cycles were missed without anyone noticing.

The consequence is that the only protection for PEAP-MSCHAPv2 — the TLS tunnel — is not reliably in place. MSCHAPv2 itself is broken: Microsoft acknowledged in 2012 that the Marlinspike attack "reduces the security of MS-CHAPv2 to a single DES encryption (2^56) regardless of the password length", and tooling to exploit captured handshakes remains maintained. What is recovered is the NT hash, which is credential-equivalent, so password strength offers no mitigation. The credential at stake is the primary ASURITE password.

Client Provisioning with eduroam CAT

The eduroam Configuration Assistant Tool is the consortium-operated service that generates per-platform eduroam installers from a set of RADIUS and EAP details an IdP administrator supplies. It is what eduroam Operations points IdPs at instead of manual configuration instructions, and it is the mechanism that makes correct server identity validation the default rather than something a user can skip.

CAT is a configuration generator, not a RADIUS server. It does not sit in the authentication path, so adopting it is independent of the ECS migration and can be done against the current ISE deployment.

Enrollment

CAT follows eduroam's federation model: the national roaming operator controls which IdPs in its country may participate. For ASU that is Internet2 / InCommon, which issues an invitation token valid for 24 hours. Whether Internet2 enables CAT for US IdPs, and what their process is, is the first thing to confirm — support runs through help@incommon.org.

Administrative login is federated rather than local, accepting eduGAIN identities that release eduPersonTargetedID, subject-id, or pairwise-id. ASU participates in InCommon and eduGAIN, so this should work with existing credentials; the attribute release needs verifying. Social logins are available as a fallback but are not appropriate for a production service.

Institution and profile model

An institution holds one or more EAP profiles, each representing a user population with its own EAP configuration. Settings can be defined institution-wide and overridden per profile.

For ASU today that is a single profile: realm asu.edu, PEAP, outer identity anonymous@asu.edu, ASURITE credentials. The profile model becomes useful later — the consortium's own example is students on username/password with PEAP alongside staff on client certificates with EAP-TLS, which is exactly the shape a future EAP-TLS pilot would take without disturbing the existing population. A profile is only published to end users once the administrator marks it production-ready.

Supplying the realm is optional but enables the reachability testing described below, so it should be set.

What ASU uploads, and what changes

CAT expects the CA certificate that signed the EAP server certificate, always including the root and optionally intermediates, plus the server name as it appears in the certificate CN. The guide is explicit that the server certificate itself should not be uploaded, because it is presented during the EAP exchange; only the trust anchor belongs on the device.

This is a direct correction to the current Apple profile, which embeds two ASU leaf certificates — both now expired — and omits any server name constraint. Under CAT, the private CA created in phase 0 becomes the single uploaded anchor and the asu-nac CN becomes the enforced name, which is what closes the impersonation gap.

CAT also supports uploading multiple root CAs simultaneously, which allows CA rollover without a flag day: devices provisioned with both the old and new roots accept server certificates from either, provided the CN does not change. The documented procedure is a migration profile carrying both roots, then the server certificate swap, then a permanent profile carrying only the new root.

That procedure is how ASU moves from the InCommon public CA to a dedicated private CA without a disruptive cutover, and it is the mechanism phase 0 should use.

Distribution

Installers can be published on CAT's own download area, which performs OS detection and offers the matching installer, or downloaded by the administrator and served from ASU's own pages. Both can be mixed: individual platforms can be redirected to an ASU support page while the rest download from CAT. This means the existing KB articles can become thin wrappers pointing at the installer rather than step-by-step configuration walkthroughs.

Two integration hooks are relevant if provisioning needs to reach managed devices as well as BYOD: a web API that can enumerate profiles and fetch installers programmatically, and Windows installers that accept a /S silent flag for embedding in a larger institutional package.

Media properties worth setting for ASU: any additional SSID on which eduroam credentials are valid, wired 802.1X if any ports use it, and suppression of a bootstrap or onboarding SSID so devices do not prefer it over eduroam afterward. The eduroam SSID itself is always configured and does not need entering, and CAT silently removes legacy WPA/TKIP profiles it finds. OpenRoaming is available but must be enabled by the NRO and requires DNS work, so it is out of scope here.

Android

Android is the platform with no working path today, and CAT improves it but does not fully solve it. The CAT Android app installs only one certificate and therefore cannot support CA rollover; the consortium directs IdPs to geteduroam for Android instead. Android below 4.3 is not supported and will not be. Practically this means geteduroam is the Android answer, and the CAT rollover procedure needs an Android-specific plan — either isolating Android in its own profile with a single root, or relying on geteduroam throughout.

Realm reachability testing

CAT includes a live diagnostic that sends probes through the real eduroam infrastructure to the configured realm. It reports on NAPTR records for dynamic discovery, authentication round-trip times above five seconds, RADIUS attribute handling, certificate chain structure and validity, and — directly relevant here — whether the server can send and receive UDP fragments, which the guide notes some firewalls choke on. An optional positive-authentication test is available with short-lived test credentials.

That single feature exercises three of this plan's open risks against the real federation: fragmented UDP carrying large EAP payloads through the NLB, added latency from the AWS path, and server certificate correctness after the private CA migration. It is the cheapest available verification for phase 1 and phase 2 cutover readiness and should be used as an explicit gate rather than an afterthought.

Limits

CAT does not replace the helpdesk, does not guarantee installation succeeds on modified devices, and does not cover every platform — the current compatibility matrix lives on the CAT front page and support tracks vendor end-of-life dates. eduroam Managed IdP is a separate consortium service that hosts RADIUS and issues client certificates; it is not in scope, since ASU is standing up its own RADIUS service.

Tools In Use

  • FreeRADIUS 3 — RADIUS server; the eduroam consortium's recommended implementation
  • AWS ECS — container runtime for the FreeRADIUS service; launch type is an open question (see Risks)
  • AWS Network Load Balancer — UDP/1812 ingress; Fargate has supported UDP load balancing via NLB since July 2020
  • OpenTofu — infrastructure-as-code; new ECS and NLB modules required, as the dco-terraform library has neither today
  • Jenkins — CI/CD for plan and apply, and for container image build
  • AWS Direct Connect — path from on-premises wireless controllers to the AWS-hosted service
  • Active Directory — identity store for IdP-role authentication, required by PEAP-MSCHAPv2
  • eduroam Federation Manager — Internet2 portal for registering RADIUS addresses and realms, and for the authentication log viewer
  • eduroam CAT — consortium-operated client configuration provisioning, and the source of the realm reachability diagnostics used as a cutover gate
  • geteduroam — the consortium's recommended Android path, since the CAT Android app cannot support CA rollover

Under Evaluation

  • EAP-TLS — the only option where a compromised tunnel yields nothing reusable, since there is no inner method and the private key never leaves the device. RFC 9190 strengthens it further by always providing forward secrecy, never disclosing the peer identity, and mandating revocation checking. It also removes the identity-store dependency from authentication entirely, which would resolve the runtime question below. Cost is a client certificate lifecycle on a BYOD population, so it is a candidate future phase rather than part of this migration.
  • Separate purpose-limited network credential — issuing a network-only credential distinct from the ASURITE password converts a harvested credential from account takeover into Wi-Fi misuse, and would allow a container-friendly credential store instead of an NT-hash backend. Costs a credential store and an enrollment path.
  • Health check strategy — NLB has no UDP health check; UDP target groups must be probed over TCP, HTTP, or HTTPS, which proves a socket answers but not that authentication works. Candidates: an ECS container health check running a local radclient probe so ECS replaces unhealthy tasks and deregisters them natively, or the AWS RADIUS witness pattern (sample-nlb-radius-witness). The witness reconciles target group membership directly, which conflicts with an ECS service that owns registration for its own tasks, so the container health check fits better and the witness is reduced to an alarming role if used at all.
  • RadSec — would give NLB a real TCP health check and remove shared-secret-by-source-IP peering. Whether the US TLRS accepts RadSec peering is unconfirmed and needs an answer from Internet2.
  • Commercial onboarding platforms — SecureW2 and similar are used by some US institutions in place of CAT and bundle certificate issuance for an EAP-TLS path. Worth a comparison only if CAT proves unavailable through Internet2 or insufficient for the device population.

Scope

Phase 0 — Certificate trust and provisioning remediation

Independent of the migration and should not wait for it. This is the remedy eduroam prescribes, and it closes a current policy breach.

  • Private CA that issues certificates exclusively to the eduroam RADIUS servers. eduroam guidance makes the server-name check optional only under an exclusive CA, and names this as the only configuration that is secure on supplicants which cannot express a server name
  • RADIUS server certificate reissued from that CA, with a lifetime that removes the annual user-facing profile renewal
  • Apple configuration profile rebuilt against the private CA, with TLSTrustedServerNames populated and the public CA anchors removed
  • eduroam CAT adopted for provisioning, and geteduroam delivered as the Android path — currently there is none that works. See Client Provisioning with eduroam CAT
  • Transition from the InCommon public CA to the private CA executed using CAT's documented rollover procedure — a migration profile carrying both roots, then the server certificate swap, then a permanent profile carrying only the new root — so no device loses connectivity at cutover
  • Published details brought in line with eduroam requirements: issuing CA, server certificate CN, supported EAP types, and which credential to use
  • Manual configuration instructions removed in favour of the provisioning tool; the instruction to skip CA validation removed outright
  • CAT realm reachability check run against the current ISE deployment to establish a baseline before any AWS work begins
  • Coordination with Certificate Lifecycle Automation

Doing this first also de-risks the migration: once clients trust an ASU-controlled private CA, the RADIUS implementation and hostname can change beneath them without touching any device.

Phase 1 — SP role on ECS

The SP role is stateless proxying with no identity-store dependency, so it validates the container, network, and peering design at the lowest blast radius.

  • FreeRADIUS 3 container image, built and published from a Git repository
  • ECS service definition, task role, and logging to CloudWatch
  • Internal NLB with a UDP/1812 listener for on-premises wireless controllers over Direct Connect
  • clients.conf for the wireless controllers, keyed by controller address and shared secret
  • Outbound proxy configuration to tlrs1.eduroam.us and tlrs2.eduroam.us, with a fail-over home server pool and Status-Server checks
  • Egress path with a static address registered in Federation Manager
  • Operator-Name set in the REALM namespace, and CUI generation keyed on it
  • Attribute filtering on pre-proxy and post-proxy, retaining Operator-Name and Calling-Station-Id
  • F-Ticks logging to satisfy eduroam SP logging requirements
  • Verification that EAP methods pass through unfiltered
  • Verification that fragmented UDP carrying large EAP payloads survives the NLB path, using the CAT realm reachability check as the test
  • Health check mechanism selected and implemented
  • OpenTofu modules for ECS service and NLB, published to Artifactory
  • Parallel run against ISE with a subset of controllers before cutover

Phase 2 — IdP role on ECS

  • Internet-facing NLB with static addresses registered in Federation Manager, accepting UDP/1812 from TLRS1 and TLRS2
  • PEAP termination with the server certificate issued in phase 0
  • MSCHAPv2 against Active Directory. This requires an NT-hash path, meaning ntlm_auth or winbind with a domain-joined machine account, since AD does not expose unicodePwd over LDAP
  • Runtime decision: whether a domain-joined container is workable on Fargate or whether ECS on EC2 is the better fit (see Risks)
  • Network path from the tasks to Active Directory
  • inner-tunnel configured with proxying disabled
  • Realm handling for asu.edu and any additional ASU realms
  • CAT realm reachability check passing against the new service, covering UDP fragment handling, round-trip time, and certificate chain validity, as a cutover gate
  • Parallel run with ASU-realm authentications served by both ISE and the new service, compared before cutover

Phase 3 — Cutover and decommission

  • Federation Manager updated to point only at the new addresses
  • ISE eduroam configuration removed
  • ISE decommissioned, contingent on internal network access control having completed its move to AGNI
  • Runbook, alerting, and on-call documentation

Out of scope

Future Phases

  • EAP-TLS migration. The only method where tunnel compromise yields no reusable credential. Removes NT-hash storage, the winbind dependency, and the runtime constraint in phase 2, at the cost of a client certificate lifecycle. Deferred because it is an enrollment programme rather than a configuration change, and because eduroam's own remedy for the current exposure does not require it.
  • Separate network credential. Independently valuable whether or not EAP-TLS is adopted, since it caps the blast radius of a harvested credential.
  • RadSec peering with the TLRS, if Internet2 supports it.

Logistics

Product registration

Proposed key eduroam, product name eduroam, family authn (Authentication). The key is free in the product map with no near collisions. A plain descriptive name follows the precedent of krb (Kerberos) and duo (Duo) in the same family; no backronym is needed for a service whose name is already the industry term.

authn is the right family: eduroam is federated authentication, and the family already holds this service's dependencies and peers — krb, dcnrad (DCN RADIUS), and duo. The alternative is nac (Network Access Control), where cise (Cisco Identity Services Engine) and agni sit; that grouping is by what authorizes network access rather than by authentication function.

ISE appears in the map as both cise (nac) and cnac (authn), both placeholders. Registering eduroam separately keeps this service's lifecycle independent of the ISE placeholders, which retire with the appliance.

Status stays draft until the key is registered, then moves to planned.

AWS accounts

New product accounts to be vended. Region, and whether a non-production environment is needed for the parallel run, are open questions.

Risks

Risk Likelihood Impact Mitigation
Credential harvesting via impostor RADIUS server, present today High High The profile anchors to public CAs with no server-name check, and Android is told to skip validation entirely. A captured PEAP-MSCHAPv2 handshake yields the NT hash offline regardless of password strength. Phase 0 closes this and does not depend on the migration
PEAP-MSCHAPv2 forces a stateful backend into a stateless runtime High Medium MSCHAPv2 needs an NT hash, so FreeRADIUS needs ntlm_auth/winbind and a domain-joined machine account — machine password rotation, keytab storage, and winbind cache in a disposable task. Evaluate ECS on EC2 with a persistent host against Fargate, or proxy inner MSCHAPv2 to an existing PSN during transition
Ingress and egress present different source addresses to TLRS High High Inbound arrives at the NLB address while outbound leaves via NAT gateway. TLRS peers RADIUS by source address and shared secret, so a request from an unregistered address is silently dropped. Register both addresses in Federation Manager, or converge them, and verify bidirectionally with Internet2 before cutover
Transport-layer health check keeps a broken server in rotation High High NLB cannot health-check UDP at the application layer, so a task that answers packets but rejects every authentication keeps receiving traffic. Implement a radclient-based container health check so ECS replaces the task, and alarm separately on authentication success rate
Identity store outage triggers a task replacement loop Medium High If the health probe exercises end-to-end authentication, an AD outage fails every task at once and ECS cycles the whole service, removing capacity instead of surfacing the error. Scope the container probe to RADIUS liveness and detect identity-store failure through a separate alarm
Fragmented UDP carrying large EAP payloads dropped in the NLB path Medium High RFC 7593 §3.4 documents EAP payloads exceeding 1500 bytes and firewalls discarding non-first fragments, producing failures only for specific EAP types and certificate sizes. AWS does not document NLB reassembly behaviour for UDP. Test before cutover and cap fragment_size on the EAP module if reassembly proves unreliable. RFC 9191 covers the general problem
EAP conversation state lost on task replacement Medium Medium EAP is multi-round-trip and FreeRADIUS holds state in task memory. NLB's UDP flow hash keeps a conversation on one task, but a deployment or scaling event mid-conversation forces re-authentication. Set deregistration delay, deploy in low-usage windows, and confirm whether session caching can be shared
SP configuration inadvertently filters EAP methods Low High eduroam requires transparent proxying of every EAP method. A hardening step that restricts EAP types — reasonable on the IdP side — silently breaks visitors whose home institution uses an excluded method. Keep the SP and IdP virtual servers separate and assert pass-through in the test plan
Server certificate rotation breaks provisioned clients Medium High Clients pin the CA and, after phase 0, the server name. Rotate within the same private CA and coordinate any name change with a profile refresh
Direct Connect failure isolates wireless controllers from RADIUS Medium High Moving RADIUS off-premises makes eduroam dependent on Direct Connect. Confirm redundancy and decide whether a fallback path or on-premises survivability is required
No existing ECS or NLB OpenTofu modules High Low The dco-terraform library covers EC2, EKS, and networking but not ECS or NLB. Build and publish both as reusable modules rather than inlining them in the product repository
ISE decommission blocked by AGNI timeline Medium Low The ISE cluster cannot retire until internal access control has moved to AGNI. Track that dependency explicitly; eduroam cutover does not have to wait for it

Success Criteria

  • ASU eduroam users authenticate successfully when roaming at other institutions, served by the new service
  • Visitors from other institutions authenticate successfully on the ASU eduroam SSID, proxied by the new service
  • Federation Manager lists only the new RADIUS addresses, and both TLRS peers reach them
  • Client configuration is provisioned by tooling on every supported platform, including Android, with server identity validation enforced and no documented path that disables it
  • The RADIUS server certificate chains to a CA that issues to nothing else
  • eduroam is removed from ISE, and ISE carries no remaining production workload
  • Service configuration, container image, and infrastructure are defined in Git and deployed by pipeline, with no manual changes to running tasks
  • An authentication failure caused by an identity-store outage produces an alert, and a task that cannot authenticate is removed from rotation automatically
  • Rollback to ISE is achievable during the parallel-run period by reverting the Federation Manager address list

Open Questions

  • Does the Windows configuration KB specify PEAP-MSCHAPv2 to match, and does it also instruct users to skip validation?
  • How many ISE policy service nodes currently carry eduroam traffic, and what is the authentication volume? This sizes the ECS service and the AD request rate
  • Where does Active Directory live, and how do the tasks reach it — same VPC, peering, Transit Gateway, or Direct Connect?
  • Is a domain-joined container workable on Fargate, or does PEAP-MSCHAPv2 push the runtime to ECS on EC2?
  • Does the US TLRS support RadSec peering, and would that change the phase 1 ingress design?
  • Can the inbound NLB address and the outbound egress address be made the same, or do both need registering in Federation Manager?
  • Does the NLB path preserve fragmented UDP datagrams carrying large EAP payloads?
  • Is Operator-Name sent by ISE today, so that CUI values stay stable across the migration rather than changing for every user at cutover?
  • Do the wireless controllers stay on-premises permanently, and what is the Direct Connect redundancy posture?
  • How many environments are needed: production only, or a non-production peer for the parallel run?
  • Does Internet2 / InCommon enable eduroam CAT for US IdPs, and what is their invitation process? Enrollment requires an NRO-issued token, so this gates all of phase 0's provisioning work
  • Does ASU's InCommon/eduGAIN identity release eduPersonTargetedID, subject-id, or pairwise-id for CAT administrative login?
  • Is there an existing CAT entry for ASU to claim rather than create?
  • Which client platforms need provisioning coverage, and does CAT's current compatibility matrix cover them — particularly anything beyond Windows, macOS, iOS, and Android
  • Is there a bootstrap or onboarding SSID that CAT should suppress after eduroam is configured?
  • Are any wired ports using 802.1X with eduroam credentials, which CAT can also configure?
  • Who operates this service after cutover, and what is the on-call path?

References

Decisions

Date Decision Rationale
2026-08-05 Product key eduroam, name eduroam, family authn Key is free with no near collisions. Plain naming follows the krb and duo precedent in the same family. eduroam is federated authentication rather than network access control policy
2026-08-05 Retain PEAP-MSCHAPv2 as the IdP EAP method The current client configuration must keep working. eduroam's prescribed remedy for credential exposure is an exclusive private CA plus automated provisioning, not an EAP method change, so retention is compatible with closing the security gap
2026-08-05 Kerberos ruled out as the IdP authentication backend PEAP-MSCHAPv2 requires an NT hash. Kerberos validates only a cleartext password and cannot produce one, so retaining the method requires an NT-hash-capable backend
2026-08-05 Certificate trust remediation sequenced ahead of the migration as phase 0 It closes a current policy breach, does not depend on the migration, and de-risks it — once clients trust an ASU-controlled private CA, the RADIUS implementation and hostname can change without touching any device

Changelog

Date Status Change
2026-08-05 draft Initial draft
2026-08-05 draft Added Client Provisioning with eduroam CAT section; folded CAT's multi-root rollover procedure into phase 0 and its realm reachability check into phase 1 and phase 2 as a cutover gate; promoted geteduroam to committed tooling as the Android path