Closed grawity closed 3 years ago
I suppose that this misnomer has occurred because back in 2014, I couldn't get the configuration that had worked at my home institution to work at the institution I was visiting. Perhaps this was because a change had occurred at the home institution, or a certificate change (some time between me disconnecting at home and connecting at the institution I was visiting). Unfortunately, I do not have the old configuration and certificates lying around to trace back the root cause.
Anyway, thanks for clearing this out, and I will issue a take-down notice. People should probably(?) just use the installers available at https://cat.eduroam.org/ these days, and keep an eye on home institution certificate changes.
One more thing, which are the "opaque" EAP packets?
People should probably(?) just use the installers available at https://cat.eduroam.org/ these days
CAT will probably work best, especially with the recently introduced "hosted realm" service (where the CAT system also stores account information and issues EAP-TLS client certificates for every user). [I don't know whether any institution actually uses that service]
Windows 8 and later implement SSH-style "trust on first use" by remembering the certificate's fingerprint, so they can get away without requiring to manually configure server certificates. Unfortunately at least wpa_supplicant doesn't have a simple method for implementing this, as far as I know.
One more thing, which are the "opaque" EAP packets?
By "opaque" I mean that visited networks' RADIUS servers do not attempt to understand the contents of the EAP-Message attribute, they just pass it through (to the upstream server).
I couldn't get the configuration that had worked at my home institution to work at the institution I was visiting.
Probably unrelated to your problem, but I have seen many visitors' connections fail due to nonstandard identity formats (which the home institution recognizes, but the rest of Eduroam does not). For example, some people forget to add the @realm
entirely, others use Windows NT style DOMAIN\user
names.
This part does not make sense; the reality is practically the opposite.
The purpose of Eduroam is that someone could get an account from one institution (the "home" institution), and use that account anywhere else in their travels (the "visited" institutions).
This is implemented by forwarding all authentication requests (based on your identity's
…@realm
suffix) to the corresponding "home" institution. No matter where you are, your wpa_supplicant still ends up talking to your "home" institution's RADIUS server. Your "visited" institution always sees the exact same thing: just your anonymous_identity followed by opaque EAP packets.Different home institutions configure their RADIUS servers differently. One home institution may use password hashes via EAP-PEAP/MSCHAPv2, another may use plain passwords via EAP-TTLS/GTC, yet another may use client certificates via EAP-TLS.
This means that the diverging settings, which are practically always related to authentication (EAP and subprotocols), depend only on the home institution and not on the visited institution.
(The link layer settings, which do depend on the visited institution, are identical everywhere: eduroam is always provided over WPA2-AES-Enterprise.)
The conclusion is that whether a config works or not depends mainly on your home institution, not on your physical location. If you got an account at
foo.edu
, you can use the configuration fromfoo.edu
and it will work everywhere.On the other hand, if you attempt to use "generic" instructions, those are not guaranteed to work (depending on how much of a BOFH the home institution's sysadmin is). Fortunately, most home institutions implement PEAP/MSCHAPv2 because that's what generic Windows systems want, but that does not mean that all of them will.