Subject: [perpass] RADIUS is targeted by GCHQ

From: Watson Ladd <[email-masked]>
Date: Sat, 5 Apr 2014 10:25:13 -0700

Dear all,
https://s3.amazonaws.com/s3.documentcloud.org/documents/1102570/full-spectrum-cyber-effects-final.pdf
explains that RADIUS data is being used to find TDIs. I have no idea
what a TDI is, but from the document it looks like it contains
information about specific users.

Furthermore, BGP/MPLS is being exploited. Predictable, given how often
this happens by "accident".  Anyone who knows more about RADIUS and
BGP should take a look and see what is going on/what mitigations are
required.

Sincerely,
Watson Ladd

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2014 20:46:30 +0200

TDI (as described on slide 15) is 'target geographical identifiers'.

RADIUS would allow you to find out where someone is located based on his
or her point of attachment in the network.

On 04/05/2014 07:25 PM, Watson Ladd wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 5 Apr 2014 12:00:25 -0700

> Dear all,
https://s3.amazonaws.com/s3.documentcloud.org/documents/1102570/full-spectru
m-cyber-effects-final.pdf
> information about specific users.

RADIUS is normally used as part of network access authentication, between a
network access point and an authentication service. Unless precautions are
taken, monitoring the RADIUS traffic can reveal the identity of users
connecting to specific networks.  It is easy to see the implications for
pervasive monitoring.

There are two basic ways to protect RADIUS traffic from this monitoring. One
possibility  is to make sure that the actual user identities are only
transmitted in encrypted EAP payloads, such as PEAP, but this requires
scrubbing all implementations and making sure that they properly implement a
correct EAP variant. A stronger defense is to encrypt the traffic between
access point and authentication server. The RADIUS specification suggested
using IPSEC, compatible with the UDP transport. RFC 6614 specifies how to
protect RADIUS traffic with TLS. 

Either TLS or IPSEC for RADIUS will thwart pervasive monitoring.

-- Christian Huitema

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2014 21:00:27 +0200

> Either TLS or IPSEC for RADIUS will thwart pervasive monitoring.

If someone gains access to the backend database of the RADIUS server
then you are unfortunately in trouble. It is also worth noting that both
RADIUS and Diameter deployments have lots of intermediaries (as noted in
this privacy reviews:
http://www.iab.org/wp-content/IAB-uploads/2011/07/ABFAB-privacy-review.txt
http://www.iab.org/wp-content/IAB-uploads/2011/07/AAA-privacy-review.txt

What you can then see is probably very similar to this:
http://www.zeit.de/datenschutz/malte-spitz-data-retention

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 5 Apr 2014 12:53:49 -0700

> http://www.zeit.de/datenschutz/malte-spitz-data-retention

Hannes is correct, the encrypted transport will only protect against passive monitoring of the RADIUS traffic. There are two other obvious attacks, monitoring at intermediate servers and monitoring at the authentication server itself. And the references are worth reading again. Were they ever published as an RFC?
The monitoring at intermediate servers and proxies may be mitigated somewhat by the choice of appropriate EAP methods, in which the user name is obfuscated in the outer envelope and only revealed to the server in the encrypted EAP payload.
As for the attack against authentication servers, they are somewhat beyond the reach of the IETF. In fact, if I am not mistaken, the European data retention rules require that network providers keep that kind of information available for 18 months, and provide it on request. We can expect similar rules to appear in other regions. But we should at least try ensure that if data has to be revealed, this is done with proper process and is applied on a case by case basis.

- -- Christian Huitema

---

From: Stefan Winter <[email-masked]>
Date: Tue, 08 Apr 2014 15:49:04 +0200

Hi,

>> Either TLS or IPSEC for RADIUS will thwart pervasive monitoring.

As an author of RFC6614 on RADIUS/TLS, I try to keep an ear on the
ground when it comes to deployment in real life.

One of the things I hear occasionally is that people read the tag
"Experimental" and conclude that this is something they don't want to do.

That's a real shame. In eduroam, we are now using RADIUS/TLS on numerous
international aggregation links. It has some usability issues (PKI much
more complex to deploy than "good old" shared secrets) and some spurious
transmission issues (reported by some people on busy links - I suspect
head-of-line blocking at play) - but overall this is perfectly usable in
real life.

Maybe the time to move it from Experimental to Standards Track has come.

> http://www.zeit.de/datenschutz/malte-spitz-data-retention

While that's totally true - this isn't perpass is it? Yes, there are
proxies, and there are EAP home servers; if you break into them then you
can do lots of fancy things. But you are not a pervasive *passive*
attacker any more.

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: +352 424409 1
Fax: +352 422473

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

---

From: Stefan Winter <[email-masked]>
Date: Tue, 08 Apr 2014 15:51:48 +0200

> The monitoring at intermediate servers and proxies may be mitigated somewhat by the choice of appropriate EAP methods, in which the user name is obfuscated in the outer envelope and only revealed t…

Good choice of an EAP method will protect the password, and may protect
the username (it is up to John Doe on his computing device to configure
anonymous outer identities correctly - or not; guess what's the default
on most people's brains ;-) ).

There is still plenty of metadata to learn from the RADIUS packet, even
in the absence of username and password. If you control the
intermediary, mobility profiles come easy.

Greetings,

Stefan Winter

> gpgkeys: key B6DAD39214387550 not found on keyserver
> 

Tel: +352 424409 1
Fax: +352 422473

---

From: Paul Lambert <[email-masked]>
Date: Tue, 8 Apr 2014 14:12:57 -0700

>Either TLS or IPSEC for RADIUS will thwart pervasive monitoring.
Only if correctly implemented.  The Wi-Fi industry has a pervasive problem
where the TLS certificates for the authentication servers are not
validated by all devices.  We are putting in certificating testing to
encourage correct implementations, but it will take time to see a
significant change in products being sold.

The lack of certificate validation compounds the vulnerability of MSCHAPv2
which has been commonly used for ³enterprise" grade Wi-Fi deployments.
Some new solutions for this problem area will be available soon Š will
post when they are announced.

Paul

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 10 Apr 2014 16:55:22 +0200

"Christian Huitema" <[email-masked]> wrote
Sat, 5 Apr 2014 12:53:49 -0700:

|                               In fact, if I am not mistaken, the
| European data retention rules require that network providers keep that
| kind of information available for 18 months, and provide it on request.

There is a EU directive mandating member states to pass laws storing
some traffic data for 6 to 24 months, at the member states choice.

I know that some member states legislation requires ISP:s to store more
or less the contents of DHCP logs. I'm not sure which states, if any,
stipulate storing RADIUS logs in addition to that.

|          We can expect similar rules to appear in other regions.

Let's hope not. The data retention directive was declared invalid [0] by
the Court of Justice of EU day before yesterday.

Swedish providers are already announcing they will stop storing their
customers meta data for the purpose of data retention.

[0] http://curia.europa.eu/jcms/upload/docs/application/pdf/2014-04/cp140054en.pdf

---

From: home <[email-masked]>
Date: Thu, 10 Apr 2014 17:07:12 +0200

That data retention directive was just struck down by the eu court

http://www.laquadrature.net/en/data-retention-eu-court-of-justice-denounces-mandatory-data-retention

> On 10 Apr 2014, at 16:55, Linus Nordberg <[email-masked]> wrote:
>

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Apr 2014 10:06:40 -0700

> BGP should take a look and see what is going on/what mitigations are

Dear Watson,

FYI,
en.wikipedia.org/wiki/Telecom_Data_Intelligence

Here is a reference to a TDI acronym which seems fitting.  BGP and PKI remain avenues for MiTM events.

Regards,
Douglas Otis

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Apr 2014 11:28:05 -0700

Paul, RADIUS by itself has little to-do with device authentication
(other than carrying the packets).

Problems with EAP methods is not a problem of RADIUS.

Ciao
Hannes

---

From: Paul Lambert <[email-masked]>
Date: Thu, 10 Apr 2014 17:44:47 -0700

]-----Original Message-----
]From: Hannes Tschofenig [mailto:[email-masked]]
..
]Paul, RADIUS by itself has little to-do with device authentication
](other than carrying the packets).

Yes - RADIUS is just a wrapper, I was describing the broader system issue.  The thread mentioned pervasive capture of information and RADIUS.  

A significant path for capture of EAP information carried in RADIUS packets is via MiTM attacks when the EAP/RADIUS information is carried in TLS.  Code used for EAP/RADIUS does not always validate certificates correctly creating a path to capture the RADIUS/EAP information.   

]
]Problems with EAP methods is not a problem of RADIUS.
Yes ... but it is a system problem with the use of RADIUS.

Paul

]
]Ciao
]Hannes
]
]On 04/08/2014 11:12 PM, Paul Lambert wrote:
]>>
]>>
]>>
]>> Either TLS or IPSEC for RADIUS will thwart pervasive monitoring.
]> Only if correctly implemented.  The Wi-Fi industry has a pervasive
]> problem where the TLS certificates for the authentication servers are
]> not validated by all devices.  We are putting in certificating testing
]> to encourage correct implementations, but it will take time to see a
]> significant change in products being sold.
]>
]> The lack of certificate validation compounds the vulnerability of
]> MSCHAPv2 which has been commonly used for ³enterprise" grade Wi-Fi
]deployments.
]> Some new solutions for this problem area will be available soon Š will
]> post when they are announced.
]>
]> Paul
]>
]>
]>>
]>> -- Christian Huitema
]>>
]>>
]>>
]>>
]>> _______________________________________________
]>> perpass mailing list
]>> [email-masked]
]>> https://www.ietf.org/mailman/listinfo/perpass
]>
]> _______________________________________________
]> perpass mailing list
]> [email-masked]
]> https://www.ietf.org/mailman/listinfo/perpass
]>