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