[strongSwan] OS X/iOS clients with XAUTH

[Brian Mastenbrook]

On Feb 4, 2013, at 3:24 AM, Martin Willi <martin at strongswan.org> wrote:

>> I'm finding that clients drop after 45 minutes because the client
>> wants to rekey, but doesn't expect to have to perform XAUTH
>> authentication again.
> 
> Yes, that's a known issue with iOS clients. I didn't know the same
> applies to OS X, though.

Unfortunately this does in fact apply to OS X Lion and Mountain Lion. While I'd prefer to live in a world where those two releases didn't exist (or didn't break nearly as many things as they did), sadly, this is not that world. What happens is that the user is prompted to re-enter their XAUTH credentials when the server rerequests XAUTH authentication, even if those credentials have been saved in the VPN profile. I'm trying to keep this running in an unattended fashion, so reentering credentials doesn't work for me.

> If you do not rely on XAUTH, this is fine. However, other users do the
> opposite; they don't rely on RSA (but just use it to securely
> authenticate the gateway), and then fully rely on XAuth password
> authentication. The private key is considered "public" in such a setup,
> but we still have a good level of security (compared to XAUTH+PSK, for
> example).
> 
> Just skipping XAuth during reauthentication is not really an option
> then: There is no cryptographic binding between the old and the new
> ISAKMP SA. An attacker could hijack such a connection if it has the
> private key.

After looking into this a little more, I'm convinced this is the unavoidable consequence of Apple's implementation. When the SA is rekeyed (once an hour, regardless of the server's proposal), anyone with the same private key and with the same IP address could hijack the session. This means that the only way to make IPsec tunnel mode secure with the built in OS X/iOS client is to use no less than one certificate per user (and I'd still argue for one certificate per device, for ease of revocation when a device goes missing).

If that's the case, then XAUTH isn't adding much in the way of security anyway for OS X/iOS clients, and the fake-XAUTH mode is a perfectly acceptable way of setting up a pseudo-pure-RSA gateway. I did also test this with the Android built-in client and it seemed to work, though using Strongswan for Android is much preferred anyway due to support for IKEv2 and MOBIKE.

One might argue that there's a slight benefit if the users choose not to save the password in the VPN profile, or if the passwords rotate in some fashion (OATH HOTP?), but I'm not counting on it for my purposes, and indeed Windows (Agile VPN) and Android (Strongswan) clients are set up for pure RSA on this gateway.

>> Is there any interest in a cleaner patch for this "fake XAUTH" mode?
> 
> When I find some time during the next weeks, I'll try to have a look at
> it. Maybe there is another way how we can trick iOS to survive that
> rekeying procedure.

I wish you luck with this, but I'm not optimistic. There's a lot of brokenness in this area, and I spent quite a while fighting with it yesterday. In particular the iOS configuration profile reference (http://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/) indicates that it might be possible to disable XAUTH using a key in the VPN section that's not exposed through the iPhone Configuration Utility, but nothing I did yesterday succeeded in making this mode work.

--
Brian Mastenbrook
brian at mastenbrook.net
http:/brian.mastenbrook.net/