eduroam Development VC Minutes 2023-09-26 1530 CEST

Attendance

Attendees

  • Stefan Winter (Restena)
  • Stefan Paetow (Jisc)
  • Janfred Rieckers (DFN)
  • Mike Zawacki (Internet2)
  • Ed Kingscote (CANARIE)
  • Fabian Mauchle (SWITCH)
  • Chris Phillips (CANARIE)
  • Paul Dekkers (SURF)
  • Guy Halse (TENET)
  • Hideaki Goto (Tohoku University/NII)
  • Zenon Mousmoulas (GRNET)
  • Tomasz Wolniewicz (PSNC)
  • Maja Górecka-Wolniewicz (PSNC)
  • Anders Nilsson (SUNET)
  • Ed Wincott (Jisc)
  • Philippe Van Hecke (BELNET)
  • Maxime Houlbert (Renater)
  • Louis Twomey (HEAnet)
  • Janos Mohacsi (KIFÜ)

Regrets

Agenda / Proceedings

  1. Welcome / Agenda Bashing

CP: if we were to ask Microsoft about what to do about RADIUS, what would be the reference implementation??
(reference for prior art from MSFT: https://learn.microsoft.com/en-us/azure/active-directory/architecture/multilateral-federation-introduction)

notes: Minimum: Have RADIUS/TLS (RadSec) (Preferably also RADIUS/TLS-PSK) be supported on AzureAD natively to use
do not require AADDS but have something that does RADIUS

  • PEAP, MS-CHAPv2, TTLS (obviously??) is there a priority order here(yes)? 1. EAP-ttls, 2. PEAP, 3. MS-CHAPv2 (as an inner-tunnel method)

  • Support whatever supplicants that are in Windows 11

  • attend the next RADEXT item at IETF (and maybe EMU (EAP Methods Update) WG too, e.g. for EAP-FIDO)

    end of the rainbow item ‘EAP-FIDO’ so with passkeys.
    (ie )

  • be reliable on the client side.

  • how to pace/ keep on the current curve for client updates (is this ‘be MSFT developer??’)

Aspirational?:
items on the windows profiles that corrupt the profile itself and the client.

Paul: We’re investigating a login chicken/egg issue with online identities, while geteduroam EAP-TLS credentials are stored in a personal store, and after that Windows corrupts the profile but that’s the EAP side of things

Proposal from HPE Aruba - Connecting CloudAuth into eduroam
^^^
this sounds GeGC oriented and welcome any input and thoughts of course

CP:hot take: same as above – RadSec only? who is the operator on level 1/ emergency contact etc etc etc

side comment: would eduPKI still be the story in the AzureAD RADIUS TLS story too?

  • Yes, absolutely (SP).

StefanW: Requirements on these outsourcers?

  • the NRO needs to approve onboarding of each new customer
  • transparency about whose inst is authenticating (unique realms, distinct IPs, distinct eduPKI cert for each realm (issued from within eduroam) …)

CP:maybe the RadSec (eduPKI?) cert is the verification/access required for said infra?
StefanW: available in cat 2.1.1 for NROs to be able to request eduPKI certs for themselves and for others/on behalf of others.

risk: Aruba/vendor then becomes (tacitly?) the arbitrator to get eduroam in a given region at times for cloud like solution?
Discussed and acknowledged on the risks and that the assignment of the eduPKI cert is likely a span of control that can mitigate this and have the devices/vendors be capable, but connectivity restricted to those who possess a valid eduPKI cert for RadSec connectivity.

  1. CAT 2.1.1 maintenance release
  • preprod is up and running
  • some issues with transliteration of Greek names
  • some time October/early November could be a good time.
  • Android-specific options (IDP-admin controlled) to eliminate extra screens

2a. geteduroam apps

  • Generic update: Loads of new updates (iOS, Android, macOS, Linux (CLI/GUI), Windows), improved debugging and error handling on Android
  • Need to be conservative in releasing the new versions
    • New versions are being released together, by end of the year hopefully
    • Have to announce and give people advance warning that the new versions are coming
  • Linux packages for the geteduroam client on Linux are being built with the goal to include into upstream distributions
  • HONOR 90 issue (1.0.16 works, 1.1.0 doesn’t)

3. EAP-FIDO update

EAP-FIDO is going to the IETF (Prague meeting, planned submission just in time for the I-D cutoff)

4. IETF update

not covered

5. Recurring OpenRoaming chitchat

not covered

6. AOB / next VC

    • 10 Oct 2023 1530 CEST - clash with eduGAIN TownHall
    • Link to Internet2 TechEx23 Mobility Day Agenda (slides pending): https://spaces.at.internet2.edu/display/eduroam/Mobility+Day+at+Internet2+TechEx+2023
    • Advance Warning about certificate validation shortening to 90 days
      • Be aware that this is coming, see https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/#focusing-on-simplicity
        • Quote unquote: In a future policy update or CA/Browser Forum Ballot Proposal, we may introduce:
        • a requirement that would restrict extendedKeyUsage values in new subordinate CA and TLS server authentication subscriber certificates to only “id-kp-serverAuth.” Modifying the definition of a dedicated TLS PKI hierarchy to prohibit use of other extendedKeyUsage values (i.e., id-kp-clientAuth) in new CA certificates capable of issuing TLS server certificates more closely aligns CA practices with web browser use cases (i.e., securing connections to websites). Further, it eliminates the risk and unintended consequences of other use cases (e.g., IoT) from negatively affecting website authentication.
      • This may constitute significant pain for those NROs who have a lot of organisations using commercial certs
        • not only for NPS, but also for other software like Aruba CPPM and Cisco ISE
      • Not a problem for those using geteduroam/CAT, since the root stays the same, but the server cert rotates. Rotation/renewal method more an issue
      • Suggestions on how to:
        • Use ACME client with DNS: Lego works with Sectigo (Paul D), Acme Cli works too (Stefan W), Powershell might have APIs (Ed K)
          • Use same key + CSR (possible in Lego, may be not possible in PowerShell)
        • Use Git for repository storage and pull for each RADIUS server (Louis T)
      • Until Google clarifies whether it’ll be both Chrome (not an issue really) and Android (i.e. root trusted store for the OS), assume it’s both
        • It’ll be not supplicants rejecting, but rather Google forcing the issue with the CAs (“If you don’t implement this, we’ll boot you from our root stores”)
        • If CAs issue different profiles (i.e. ‘RADIUS server’ and ‘Web Server’), issue might be dodged, but based on past experience, they won’t (maybe GEANT can force issue with Sectigo)
  • No labels