Hi Michael,

Sorry if I wasn't terribly clear, but the patch was written by Tobias Brunner.

Brian
--
Brian Mastenbrook
[email protected]
http://brian.mastenbrook.net

Michael Gorbach <[email protected]> wrote:

>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 <[email protected]> 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
>> [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

Reply via email to