[strongSwan] OS X/iOS clients with XAUTH

[Michael Gorbach]

Brian,
	Thanks so much for your work on this patch! Do you know what Cisco does to handle the no-modeconfig-on-rekey problem? I already have a setup where every user has their own private key, but I'd like to avoid having to assign specific private IPs on a per-key basis and setting up many near-identical conn sections in the config. Also, is there any plan to incorporate this patch into a StrongSwan release (obviously as an option plugin)? Seems like this problem is significant enough that it might be worth doing so, and documenting all these discussions on the StrongSwan documentation pages for iOS / OS X connections.

Yours,
~ M.

On Feb 18, 2013, at 12:03 AM, Brian Mastenbrook <brian at mastenbrook.net> wrote:

> On 2/17/2013 12:49 PM, Michael Durket 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)?
> 
> What Apple means by this is that iOS does not support server-initiated 
> rekeying. iOS and OS X will rekey the tunnel every 45 minutes, no matter 
> what the server proposes for lifetime.
> 
> As best I can work out, Cisco's implementation returns an XAUTH OK 
> status immediately when it detects rekeying (based on the tunnel ID). 
> This could lead to the session being intercepted if two tunnels share 
> the same private key, and I could imagine it would cause failures if two 
> users with the same private key are connected behind the same NAT device.
> 
> There's a branch in git called "xauth-noauth" that adds an xauth plugin 
> that makes strongswan return an immediate xauth OK response for the 
> applicable tunnel. This means you can use private keys for 
> authentication and return the xauth response OS X/iOS needs, even if you 
> don't really need xauth. I've been testing this out and have found it to 
> work reliably with iOS 6.1 and OS X 10.8. In order to make it work, I 
> created one key/certificate per client, and assigned an IP statically to 
> each client. The client config looks something like this:
> 
> conn foo
>         rightauth2=xauth-noauth
>         rightsourceip=192.168.22.33
>         rightsubnet=192.168.22.33/32
>         rightcert=foo.cert.pem
> 
> 
> The rightsubnet clause is there because OS X or iOS don't seem to do 
> modeconfig on rekeying either, which means strongswan needs to know the 
> rightsubnet of the SA statically.
> 
> In "conn %default", I have rightauth=pubkey and have set ikelifetime and 
> keylife to 24h. iOS and OS X will always rekey before this threshold, so 
> I've kept rekey=yes for other clients.
> 
> Hope this helps,
> 
> Brian
> -- 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4371 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130218/3246a8f9/attachment.bin>