Restoring EAP-TTLS (and PEAP) support on Android

[eqvinox]

EAP-TTLS support was added (or rather, enabled) in the strongSwan Android client in 2.0.0, but then removed again in 2.0.1

as it caused major issues with commercial VPN services (one issue was that the server identity was initially enforced as AAA identity, but changing that revealed that some providers use self-signed AAA server certificates - not sure what clients accept that), hopefully proper support can be added in a future version.

Related:

• https://wiki.strongswan.org/issues/2392 (TTLS)
• https://wiki.strongswan.org/issues/3244 (PEAP)

The main issue/reason here is that EAP-TTLS/PEAP with PAP inside is the "standard" way to securely transmit unencrypted passwords, therefore enabling the RADIUS server to store hashed passwords. As is generally best practice.

NB: one possible reading of the changelog above would be that the client was trying to enforce that the name used to connect IPsec is a name permitted in the certificate received on EAP-TTLS (server identity enforced as AAA identity?). This is generally not the case. A "common" setup would be to have an IPsec service at e.g. vpn.example.net, but RADIUS is provided by radius.example.net. The certificate received in EAP-TTLS will be valid only for radius.example.net, not vpn.example.net. (This sadly means the name to match for the radius server needs to be configured — same story as with enterprise Wifi setups. In fact, using the same RADIUS server in IPsec that is already there for Wifi is a major reason for this.)

(I'm skipping the discussion page because there's not that much to discuss really… there is not much ambiguity what this feature does, the question is just whether it can be enabled in some "safe" way without breaking things.)

[tobiasbrunner]

The main issue/reason here is that EAP-TTLS/PEAP with PAP inside is the "standard" way to securely transmit unencrypted passwords, therefore enabling the RADIUS server to store hashed passwords. As is generally best practice.

Note that strongSwan doesn't support PAP (or any other inline authentication methods), it only supports tunneling EAP in these methods.

one possible reading of the changelog above would be that the client was trying to enforce that the name used to connect IPsec is a name permitted in the certificate received on EAP-TTLS (server identity enforced as AAA identity?).

It did exactly that.

This sadly means the name to match for the radius server needs to be configured

Correct, it might even require a second CA certificate to be configurable, which is why this hasn't been implemented yet. It's just too much work for too little gain.

[eqvinox]

It's just too much work for too little gain.

I'm… confused…

Enterprise 802.1X setups (including wifi) generally use EAP-TLS, EAP-TTLS+PAP or EAP-PEAP+MSCHAPv2. ref¹

EAP-TLS has the same problem with the RADIUS server identity. (I didn't ask about that in this issue because, well, I don't use EAP-TLS.)

Are you saying it's not sufficent gain to be able to use the same AAA infrastructure for 802.1X and IPsec?

(I mean, worst case I'll try to implement it myself, but, that'll take forever since I don't know the strongSwan codebase :( )

---

¹ note the linked article assumes you don't verify certificates in TTLS/PEAP, in which case everything becomes insecure. I think they want to sell their client certificate management products.

[tobiasbrunner]

Apparently not, otherwise, I'm sure there would have been some corporate sponsor to support the development of this feature in the app.

[eqvinox]

Apparently not, otherwise, I'm sure there would have been some corporate sponsor to support the development of this feature in the app.

Well. I guess they just ship whatever commercial VPN solution they bought, including proprietary clients. Unlike 802.1X/wifi, where you can't really roll your own.

This sadly means the name to match for the radius server needs to be configured

Correct, it might even require a second CA certificate to be configurable, which is why this hasn't been implemented yet. It's just too much work for too little gain.

Looking through the code, isn't the first half of this already implemented with aaa_id? Was the Android breakage simply due to the fact that aaa_id was not exposed in the client's GUI? (While you're technically right about the second CA certificate, I'd wager that ≥ 90% of setups probably use the same CA for this.)

[tobiasbrunner]

Was the Android breakage simply due to the fact that aaa_id was not exposed in the client's GUI?

Yes, the GUI, the profile format and now the managed configurations. Plus it would probably require a new VPN type similar to EAP-TLS, as enabling it by default for the EAP-username/password type caused commercial services to suddenly use EAP-PEAP with unintended consequences for users.

(While you're technically right about the second CA certificate, I'd wager that ≥ 90% of setups probably use the same CA for this.)

Not from what I saw when I enabled this feature the first time (it's been over five years ago, though). There were self-signed AAA certificates used by commercial VPN services (i.e. quite a number of users were affected), which would definitely have to be loaded and configured in the app. Could have been a misconfiguration on their end, of course, because nobody ever used EAP-PEAP, but still.

[eqvinox]

Ok, I can't quite square the combination of

Apparently not, otherwise, I'm sure there would have been some corporate sponsor to support the development of this feature in the app.

and

as it caused major issues with commercial VPN services

But, well, the world is not always logical.

Just to recap, there are actually 3 issues:

• a separate CA configuration option for all EAP methods using TLS
• supporting PAP (and maybe MSCHAPv2) inside EAP-TTLS (and maybe PEAP)
• exposing all of these features

I'll probably be back in… a year? 😆 … with a patch or two. I'm not a "corporate sponsor", but what I am is a senior C developer with an annoyance at missing things like this.

[tobiasbrunner]

Not sure what confuses you there.

• a separate CA configuration option for all EAP methods using TLS

Plus the AAA identity.

• supporting PAP (and maybe MSCHAPv2) inside EAP-TTLS (and maybe PEAP)

This is a completely separate issue and not related to this at all. And it's even less likely to happen than the other stuff, which has very low priority to begin with.

[eqvinox]

Not sure what confuses you there.

I'm confused that enabling the feature in the Android client broke a whole lot of commercial VPN services (= therefore, some variant of this must be in use quite a bit), yet noone is interested in fixing it.

• a separate CA configuration option for all EAP methods using TLS

Plus the AAA identity.

aaa_id already exists?

• supporting PAP (and maybe MSCHAPv2) inside EAP-TTLS (and maybe PEAP)

This is a completely separate issue and not related to this at all. And it's even less likely to happen than the other stuff, which has very low priority to begin with.

If that means you won't accept patches to implement this, I'd appreciate you telling me that now, before I spend time implementing it.

PAP is the only way to support hashed-at-rest passwords on the AAA server side. Anything else requires storing either cleartext passwords on the AAA server, or easily breakable ones (for MSCHAPv2). Best practices as I understand them is "cleartext in flight (over TLS) + secure at rest" > "secure in flight + cleartext at rest".

[tobiasbrunner]

I'm confused that enabling the feature in the Android client broke a whole lot of commercial VPN services (= therefore, some variant of this must be in use quite a bit), yet noone is interested in fixing it.

We just got a bunch of users complaining to us that their VPN service didn't work anymore. We didn't have any contact with VPN service providers. But given the configs with self-signed AAA certificates, I've no idea what clients these configs would be for.

In particular because IKEv2 clients actually supporting EAP-TTLS/PEAP are rare (iOS supports EAP-PEAP with EAP-MSCHAPv2 but only for configs via MDM, Android's built-in client doesn't, Windows might, but not sure which methods and to what degree). You can't compare 802.1X support to what IKEv2 clients support (e.g. iOS supports a lot more EAP methods for the former than the latter). Since VPN services are generally setup to support many different clients, I wouldn't expect this to be a very popular configuration.

aaa_id already exists?

That's a vici config option, completely unrelated to the Android app and its GUI/profile file etc.

If that means you won't accept patches to implement this, I'd appreciate you telling me that now, before I spend time implementing it.

That's not what I meant. But, of course, it always depends on the patches. However, again, these EAP methods, and I'd guess PAP on top of it in particular, aren't something many, if any, other IKEv2 clients will support. So this probably won't be a popular option.

PAP is the only way to support hashed-at-rest passwords on the AAA server side.

EAP-GTC would be another option. strongSwan supports this already, but not many other clients do (iOS does apparently for 802.1X but not IKEv2).

Best practices as I understand them is "cleartext in flight (over TLS) + secure at rest" > "secure in flight + cleartext at rest".

Yeah, but that's not what people do in practice because client support just isn't there (although, the question is what came first, the server setups that didn't require it or the clients lacking support for it).