An open discussion list for topics related to the geteduroam service

[Paul Dekkers <paul.dekkers AT surf.nl>]

Hi,

Definitely, we even went over them internally to craft a reply. The problem is you sent so many questions at the same time, it was hard to reply to them all at once.

I’m in my morning routine and was away with the team for few days, so you won’t get it now ;-) but soon. If you’re at TNC we can also get together and talk things over,

Regards,

Paul

---

Van: geteduroam-request AT lists.geant.org <geteduroam-request AT lists.geant.org> namens Mohácsi János <mohacsi.janos AT kifu.gov.hu>
Verzonden: Thursday, May 23, 2024 7:53:03 PM
Aan: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
Onderwerp: Re: Some questions and comment to the geteduroam system

 

Dear All,

    Did anybody read our questions?

    Best Regards,

            Janos

On 07/05/2024 18:38, Janos Mohacsi wrote:

Dear All,

    We started to investigate a geteduroam a while ago and we have some questions:

1. Revocation handling

How the revoked certificate planned to be handled in the FreeRadius backend? CRL or OCSP or something else?  Currently we are working on a SQL query solution which is querying the letswifi SQL database about the revoked field. Do you have a example freeradius config which is already handling the revocation?

1a. In the `src/letswifi/realm/realmmanager.php` file, the `listUserCertificates` function only uses the `expires` date i.e.The function only checks that the issued certificate has not  expired yet. What if  $user *has* a revoked certificate, i.e `revoked` is not set to NULL? Is it considered to be an user certificate? What function should be used for listing only the valid certificates of the user?  We created a a patch for listUserCertificates function which is checking the revoked attribute and listing only the valid certificates. If you need we can share the patch.

1b. How the operation of letswifi is planned?  For some reason a certificate has to be invalidated can we use "revoked" for this purpose? Is it implemented some how in the letswifi-admin portal?

2. Notification of the user

The letswifi portal should send an e-mail notification  to the user that a new device has been registered in his name to use for eduroam. Where do you think this functionality should be implemented? In which funcion? Can the letswifi portal receive the hardware and software identifier of the used OS from the geteduroam app as a parameter when logged in?  This could help identify booth the the users and admins about the particular certificate if something goes wrong. This feature would be similar to the big ones, e.g. Google, which can let you know by e-mail that someone wanted a new deviceto be used in the eduroam. I think it would be better for the user's comfort if we could present not only the certificate, but the device i.e. Linux/Android/Windows/...

3. limit of usage

How can we limit the number of allocated certificates per users? We should be able to limit the number of allocated certificates to a users, since in the current model the users in primary and secondary schools (K-12) are often sharing their accounts. Time to time we see 100s of different MAC address per day for a single username and password. Which functions should modified to able to limit usage. Wea re working on a patch we can share if you need it.

4. protection of the private keys of the users

Currently seems the private keys of the users are stored in the mySQL database. Are there any plan to protect these elements?

5. Protection and scalability of the root CA

How do you implement in larger scale the protection of Root certificate of Letswifi CA? Do yo have some interface (PKCS 11? ) to "outsource" the signing of the user certificates to a HSM modul? Do you use some HW or software HSM?  What is the scalability of your HSM solution? We are expecting about dozens of 1000 students to inquiry user certificates in the beginning of a semester.

6. Scalability of number of certificates or potential bug

The certificate serial number in real life can be 20 bytes [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#page-19). This is now 4 bytes (32 bits) in the database perhaps it should be modified  to  BIGINT, which  allows at least 8 bytes (64 bits).

7. letswifi-admin features

We have not investigated the letswifi admin features yet, but can we see somewhere the capabilities? Can we setup admins per realms? etc?

8. API usage mismatch

The letswifi-portal does not use the `profiles` data from the https://discovery.eduroam.app/v1/discovery.json JSON data structure. If we use the portal directly from a browser, then after authentication "Options for other platforms and professional users" -> "Generate a certificate for manual use" creates the eap-config file with different parameters than when using the portal via the geteduroam application.

Can you explain it? What is the purpose of different behaviour?

9. userRealmPrefixAttribute

What is the purpose of userRealmPrefixAttribute? We are planning to use it for map several realms from a single SAML2 IdP.

10. user experience

After the geteduroam application has set the eduroam wifi profile some OS is also willing to initiate a connection with *expired* and/or revoked certificates, which - correctly - the server radius infrastructure refuses. I think the problem is that after successful identification, the next authentication request to the radius server only comes if the user has disconnected from the network or turned off/on the Wi-Fi on the device. However, if the authentication is unsuccessful, it *immediately* tries again, which might load the radius server unnecessarily. Can we make geteduroam app more intelligent notifying  the user about renewal and automatically deletes the `eduroam` wifi profile after expiration.

11. CA usage

It would be nice if the generated profile could be set to include *only* the CA that signs the radius servers. Now - as far as my colleagues understand - the letswifi-portal inserts its own certificate also. We think only the radius servers need to know which CA signed the client's request.

12. SNI

If a server serves several web servers - SNI - then the geteduroam application is no longer connected to the expected server. geteduroam app should be updated to honor SNI?

Thanks in advance.

Best Regards,

            Janos

--

Janos Mohacsi
Head of International R&D, Infrastructure Division, T&I service owner
GÉANT activity coordinator in Hungary, EOSC representative

Governmental Agency for Information Technology Development
address: 1134 Budapest, Váci út 35.
mobile: +36 30 555 7599   e-mail: mohacsi.janos AT kifu.gov.hu

--

Janos Mohacsi
Head of International R&D, Infrastructure Division, T&I service owner
GÉANT activity coordinator in Hungary, EOSC representative

Governmental Agency for Information Technology Development
address: 1134 Budapest, Váci út 35.
mobile: +36 30 555 7599   e-mail: mohacsi.janos AT kifu.gov.hu

---

Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie.

This message and any attachment are confidential and are legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Please note that any dissemination, distribution, copying or use of or reliance upon the information contained in and transmitted with this e-mail by or to anyone other than the recipient designated above by the sender is unauthorised and strictly prohibited.