Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt

[Stefan Winter <[e-mail]>]

Hi,

>     I also wonder to what degree this is a "pervasive attack" issue.  If
>     the attack involves being physically close to the victim, it's hard
>     to see how the attacker would achieve a pervasive scale.
> 
> MAC address are readily picked up by any hotspot, mobile device, or by
> special monitoring devices.  Commercial systems already exist to
> aggregate, track and identify people based on unique identifiers in our
> radio transmissions.  

Another attack vector is the routing of RADIUS authentication requests
for enterprise WiFi. The client device's MAC address is transported in
the clear inside the RADIUS attribute Calling-Station-Id; so if your
RADIUS server is "somewhere on the internet" (e.g. if you are part of a
roaming consortium and send your authentication traffic via a off-site
clearing house) then anybody who happens to listen on the wire learns
about those MAC addresses and the associated user identity (or at least
the realm he comes from, if the end user was mindful enough to configure
identity privacy on his device).

Partial mitigations for that are possible; RADIUS/TLS for example makes
the clear-text transmission on IP level go away; but the fact that the
clearinghouse gets to see all traffic does not go away with that.

You should read
https://tools.ietf.org/html/draft-wierenga-ietf-eduroam-01 section 3.5 -
this issue is discussed in some detail there.

A partial solution that may make some clearing houses go away is direct
dynamic discovery of RADIUS servers as per
https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/
which can (but does not necessarily always) bypass central clearing houses.

In short: MAC addresses are NOT necessarily local to the LAN; if they
leak beyond, privacy is at risk. The LAN may be IEEE's domain; protocols
that transport information about MAC addresses on the layers above are
most certainly IETF work.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66