The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Stefan Paetow <Stefan.Paetow AT jisc.ac.uk>]

All, 

I would certainly advocate the removal of 'eduroam CAT' from the Play Store, 
given that this would simplify the instructions that universities and 
colleges would need to issue, however there would need to be a migration 
policy in place, i.e. "I set up my Android 7 with eduroam CAT, but then I 
upgraded to Android 10 and had to reconfigure my eduroam, but now it no 
longer works properly". 

If need be, I'm sure we can find a couple of Android 8 or Android 9 devices 
that we can configure with eduroam CAT and then reconfigure with geteduroam 
and see what the path would need to be. Documenting that extensively for 
eduroam-configured institutions to help their helpdesks is pretty much a 
requirement before 'eduroam CAT' disappears from the Play Store.

:-)

Stefan Paetow
Federated Roaming Technical Specialist

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp AT jabber.dev.ja.net
skype: stefan.paetow.janet


In line with government advice, at Jisc we’re now working from home and our 
offices are currently closed. Read our statement on coronavirus 
<https://www.jisc.ac.uk/about/corporate/coronavirus-statement>.

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. 
GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, 
Bristol, BS2 0JA. T 0203 697 5800.
 

On 01/09/2021, 08:10, "Stefan Winter" <cat-users-request AT lists.geant.org on 
behalf of stefan.winter AT restena.lu> wrote:

    Hello,


    as you may be aware of, eduroam CAT has a support policy: we support
    installers for OSes as long as their manufacturer supports the OS itself.


    There is also a "grace period" in that we continue to serve installers
    even beyond the manufacturer EOL so long as the installers do not need
    significant amounts of work as the CAT product evolves.


    We've dropped XP and Vista at earlier occasions because of that (EOLed
    && code changes would be needed going forward).


    We've recently received two bug reports on the eduroamCAT app (more
    details at the end) and that led me to review the EOL situation for
    Android. The best I found was the Wikipedia article:
    https://en.wikipedia.org/wiki/Android_version_history#Overview which
    suggests that 8.1 is the oldest version of Android AOSP that is still
    receiving updates (at least in principle; whether or not concrete vendor
    builds still pick up any fixes and roll them out on real hardware is
    another question). If anyone has more official statements from AOSP
    themselves on their version support policy, please enlighten us.


    The bug report would need code changes in the eduroamCAT app to address
    properly. Publishing a code change in Play Store would require the app
    to target Android API level 30, which would require even more code 
changes.


    At the same time, the geteduroam app doesn't suffer from that particular
    bug, supports anything Android 8+ (i.e. all the major versions still
    receiving security updates) and can subsume all the functionality of
    eduroamCAT on those versions.


    All this suggests that the best course of action might be to complete
    the jump from eduroamCAT to geteduroam entirely - remove the download
    buttons for Android <8 from the CAT web interface, suggest the use of
    geteduroam for all remaining versions (i.e. for 8 to 10 in addition to
    the already suggested 11).


    Depending on how significant we believe the bug to be, maybe we could
    even consider removing eduroamCAT from the Play Store altogether to
    prevent accidental usage.


    I know that discontinuing old versions is always a controversial topic,
    and particularly so for Android where ancient versions tend to live much
    longer than one might hope. Hence this mail, to open a discussion. If
    you have strong feelings about old Android versions, please reply to
    this mail.


    Greetings,


    Stefan Winter


    Bug report summary: the eduroamCAT app uses an API call that performs
    substring matching on the expected server name (on the Subject/CN
    certificate property). This was the only way and best practice on
    Android <6, but on Android 6+ it could have switched to a better API
    call (with the side-effect of working against the subjectAltName:DNS
    property instead). The old API call has a worse security posture than
    the new one: if the EAP server certificate comes from a public CA, an
    attacker can get himself a certificate where the expected name is in the
    middle of the name string. The app would consider the server name valid
    even if it ends in an attacker-controlled suffix. Since our eduroam
    setup instructions on the Wiki suggest the use of a private CA, this is
    a non-issue for those IdPs following this suggestion; but for those IdPs
    which do not follow best practice suggestions, the issue has some 
relevance.