[Swan] question about pfsgroup

[Xinwei Hong]

On Sat, Mar 31, 2018 at 3:09 AM, Paul Wouters <paul at nohats.ca> wrote:

> On Fri, 30 Mar 2018, Xinwei Hong wrote:
>
> Ping...
>>
>
> First let me say if you write an email on the 29th, and then try to
> demand an answer 1 day later, you are actually _reducing_ the chance
> of getting an answer. If you need next day support, you should look
> at commercial support. Please do not do this again.


Sorry for doing that. I usually got help pretty quickly. So, I guess I was
spoiled. :)

>
>
> Can anybody confirm the behavior? Or if I'm doing something wrong, I'd
>> like to know.
>> I see the similar behavior with racoon. But looks like Cisco is doing
>> differently, according to this page. https://www.speaknetwork
>> s.com/what-is-ipsec-vpn-pfs-perfect-forward-secrecy/
>>
>
> On Thu, Mar 29, 2018 at 5:05 PM, Xinwei Hong <xhong at skytap.com> wrote:
>>       Hi
>> If we have pfsgroup in phase2alg, ipsec will use it in ESP, e.g.
>> phase2alg=aes128-sha1;modp1536
>>
>> If we don't have it, e.g phase2alg=aes128-sha1, ipsec will use the DH
>> group from phase 1 as pfsgroup.
>>
>> How do I tell ipsec to not use any pfsgroup? I tried "pfs=no", however,
>> if the remote peer has pfsgroup, it will still accept the request. sound
>> like it follows what the spec says:
>>
>> pfs
>>
>> whether Perfect Forward Secrecy of keys is desired on the connection*(Aqs
>> keying channel (with PFS, penetration of the key-exchange protocol does not
>> compromise keys negotiated
>> earlier); Since there is no reason to ever refuse PFS, Libreswan will
>> allow a connection defined with pfs=no to use PFS anyway. Acceptable values
>> are yes (the default) and no.
>>
>>
>> Also, if both ends have totally different pfsgroup, libreswan can
>> establish connection between two peers and both side seems have different
>> settings.
>>
>> Why it still works when both end mismatches? Do we need to care about
>> pfsgroup at all? This is the case between two libreswan. When connecting to
>> other VPN stack, mismatch
>> sometimes does not work.
>>
>
> Be aware there is a difference between ikev1 and ikev2. In ikev1 the IKE
> SA is negotiated first, and then the ipsec is negotiated. In ikev2, the
> IKE and (first) IPsec SA is negotiated at the same time. This means that
> the first ipsec sa has the DH protection of the first (ike) pfs group.
>
> Therefor, in IKEv2, it makes little sense to specify different PFS for
> IKE and IPsec. So leave pfs=yes and only specify pfs in the ike= line,
> and you get the same pfs for the first ike/ipsec and any further ipsec
> sa's. If you have multiple ipsec sa's for one ike sa, you would never
> know which connection is brought up first (under the first pfs group) and
> which is brought up second (under the second pfs group).
> *Therefor, libreswan does not allow different pfs groups between
> ike/ipsec.*


 I tried different algorithms in ike and esp.  libreswan did not fail.,e.g.
I have this in log:

000 vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16":   IKE
algorithms wanted: AES_CBC(7)_256-SHA1(2)-*MODP1024(2)*
000 vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16":   IKE
algorithms found:  AES_CBC(7)_256-SHA1(2)-MODP1024(2)
000 vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16":   IKE
algorithm newest: AES_CBC_256-SHA1-MODP1024
000 vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16":   ESP
algorithms wanted: AES(12)_128-SHA1(2); pfsgroup=MODP1536(5)
000 vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16":   ESP
algorithms loaded: AES(12)_128-SHA1(2)
000 vpn-5653427:
"conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16":   ESP
algorithm newest: AES_128-HMAC_SHA1; pfsgroup=*MODP1536*

If I understand the log correctly, it shows different pfs/dh groups are
used in ike/ipsec. Or do I misunderstand anything?


>
So the advise is to never specify the modp argument on the esp= line,
> which means use the same one as used for ike.
>
I understand the advise. We sometime need support client using other VPN
stack, so I want to understand how it goes when things mismatch.


> There is one exception in the upcoming 3.24 release to work around a
> Windows bug using the ms-dh-downgrade=yes option, which allows a
> different (weaker) modp group because the Windows bug causes a rekey
> to use the wrong group.
>
> Paul
>

Thanks,
Xinwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180331/29adfec7/attachment.html>