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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http:/brian.mastenbrook.net/ >> _______________________________________________ >> Users mailing list >> [email protected] >> https://lists.strongswan.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.strongswan.org/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
