Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misinformation in README #23

Closed
grawity opened this issue Aug 10, 2018 · 2 comments
Closed

Misinformation in README #23

grawity opened this issue Aug 10, 2018 · 2 comments

Comments

@grawity
Copy link

grawity commented Aug 10, 2018

Some institutions do offer raw wpa_supplicant documentation, but do so in an ad-hoc fashion — without any guarantee that the configuration will work at any other institution, defeating the purpose of Eduroam.

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 from foo.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.

@oleks
Copy link
Owner

oleks commented Aug 15, 2018

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?

@grawity
Copy link
Author

grawity commented Aug 15, 2018

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.

@grawity grawity closed this as completed Aug 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants