[strongSwan] OS X/iOS clients with XAUTH

[Kris Foster]

Unfortunately the ISAKMP SA just expires, then the IKA SA never gets rekeyed.

Kris

On Sun, Feb 17, 2013 at 7:37 PM, Michael Gorbach <michael at mgorbach.name> wrote:
> Would completely disabling re-keying in StrongSwan resolve this issue?
> If so, what are the security consequences?
>
> ~ M.
>
> On Feb 17, 2013, at 1:50 PM, Michael Durket
> <durket at highwire.stanford.edu> wrote:
>
>> I'm a little puzzled here. Apple's own website has a document "VPN Server for iOS Devices: IPSec settings" (at help.apple.com/iosdeployment-vpn/mac/1.2/#app36c95bff) that states it does not support Re-keying of phase 1 and recommends rekeying times on the server of 1 hour. But in an earlier section of the document, it states that it supports "Client and server certificates for IPSec authentication, with optional user authentication via xauth.".
>>
>> If this is so, and a user of a real Cisco VPN server sets it up to communicate this way, do their iPad/iPhone users regularly complain about being dropped every 45 minutes or so or not? If not, what is a real Cisco VPN doing to overcome this problem with xauth  that strongSwan is not? Or do Cisco VPN owners configure their VPNs for iOS devices to use some other authentication mechanisms and avoid xauth entirely because of this issue (and if so, what do they use)?
>>
>>
>> On Feb 4, 2013, at 7:31 AM, Brian Mastenbrook wrote:
>>
>>> 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/
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.strongswan.org
>>> https://lists.strongswan.org/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users



-- 
--
Kris