eduroam development VC, 25 July 2017, 1530 CEST
=========================================
Attendees
--------------
Stefan Winter, RESTENA
Philippe Hanset, ANYROAM
Maja Gorecka-Wolniewicz, PIONIER
Brian Epstein, Institute for Advanced Study
Tomasz Wolniewicz, PIONIER
Žilvinas Vaira, LITNET
Pedro Simões, FCCN
Ingimar Jonsson, RHnet
Zenon Mousmoulas, GRNET
Louis Twomey, HEAnet
Apologies
--------------
Reimer Karlsen-Masur, DFN-CERT Services GmbH
Agenda
-----------
1. Welcome, agenda bashing
Phillippe sends a mail to the list about K12 and the ability to filter access (mandatory proxy).
2. FreeRADIUS vulnerability
A fuzzer has found approx 10 CVEs in FreeRADIUS. Most of them are related to DHCP functionality (which is not usually used in an eduroam context), and the remaining bugs require that an authorized RADIUS client (=eduroam SP) sends malformed RADIUS attributes to do harm at an IdP. This scenario is improbable in an eduroam context, but of course possible (SP here means "any SP in the eduroam hierarchy - source could be every single AP serving eduroam"). So, better to update, but not a situation as urgent as Heartbleed.
On 2017-07-17 17:27, Alan DeKok wrote:
> On Jul 17, 2017, at 10:19 AM, Brian Julin <BJulin@clarku.edu> wrote:
>> Question: Of the bugs affecting RADIUS protocol itself, it looks like they apply to
>> some attributes that to many of us would be considered esoteric... is an attribute
>> filter going to kill those before the affected code gets hit, or not?
>
> Nope. The code gets hit before any "unlang" gets run. It's in the
> packet decoding routines.
Not sure if this matches the above statement: require that an authorized client sends malformed attributes
http://freeradius.org/security/fuzzer-2017.html
We could ask eduroam OT to filter the attributes in question inside Radiator, but it does not look like it is worth the effort.
We should tell eduroam admins that it is a bad idea to run a RADIUS/UDP server open to the world. For RADIUS/TLS, even if the port is open to the world, the ability to send the malicious datagrams is only possible after passing the TLS setup with an authorized eduroam SP certificate.
3. IETF Updates
IETF has been struggling with participation level in the RADIUS Extensions working group for years, with occasional lows of below 5 people in meetings and almost no life signs on the mailing list. At IETF99, suggested to shut down the working group. The documents still in the queue will be processed, RADIUS/TLS will be re-classified from "Experimental" to "Standards Track" without changes. New work, e.g. updating RADIUS/TLS further, has alternative channels such as the IETF opsawg working group.
Alan DeKok wants to make freeradius.org the de-facto standards body for all questions RADIUS and publish relevant documents there. Stefan promised him to send documents with an impact to eduroam to our group mailing list for additional scrutiny.
4. AOB / Next VC
* 8 Aug 2017, 1530 CEST
