Subject: [IPsec] Question about PFS in IKEv2

From: Yoav Nir <[email-masked]>
Date: Thu, 28 May 2015 12:28:01 +0300

Hi

This may have been discussed before, but I haven’t found such discussion. Apologies in advance if this is a stupid question.

Suppose we have to VPN peers configured to set up a tunnel between them. Suppose further that the IKE SAs are significantly longer-lived than the IPsec SAs.

PFS is configured on both sides, but there are no matching groups (perhaps GW-1 is configured with only group 19, while GW-2 is configured only with group 20).

When the tunnel is first set up, it is negotiated in the IKE_AUTH exchange. Diffie-Hellman is not performed, so the mismatched configuration is not detected - traffic flows through the tunnel.

After a while, one of the gateways attempts to rekey the tunnel, or else create a new tunnel with the same peer. This time the tunnel is set up using the CREATE_CHILD_SA exchange. The SA payload will contain the wrong DH group and the exchange will fail, resulting in traffic flow stopping.

As far as I can tell, this behavior is consistent with the RFC, but the user experience is very strange. Traffic should either flow or not flow - it should not stop at rekeying.

Am I missing something?

Thanks

Yoav

---

From: vijay kn <[email-masked]>
Date: Thu, 28 May 2015 09:38:54 +0000

Hi,
Implementations can follow this RFC extract to avoid traffic loss.

""
   Since the initiator sends its Diffie-Hellman value in the
   IKE_SA_INIT, it must guess the Diffie-Hellman group that the
   responder will select from its list of supported groups.  If the
   initiator guesses wrong, the responder will respond with a Notify
   payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
   this case, the initiator MUST retry the IKE_SA_INIT with the
   corrected Diffie-Hellman group. 
""

This point can be followed for CREATE_CHILD_SA exchange also (rekey or child sa creation) to avoid traffic loss. I mean the first rekey will fail (rekey is normally started at some point before the actual lifetime has completely elapsed), so the implementations must retry rekey with the right DH group as per info in the INVALID_KE_PAYLAOD notification.

The only problem I see is if the Gw-1 rekeyed with group19 but GW2 does not support Group19 then it can result in traffic loss. For this, the administrators of the two devices must ensure that the other end supports this algorithm before using the same in pfs configuration.

Thanks.

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Thursday, May 28, 2015 2:58 PM
To: IPsecME WG
Subject: [IPsec] Question about PFS in IKEv2

Hi

Am I missing something?

Thanks

Yoav

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 May 2015 13:15:01 +0300

Hi, Vijay.

Thanks for the response.

> On May 28, 2015, at 12:38 PM, vijay kn <[email-masked]> wrote:
> 

This is the issue for me. Of course the root cause is the configuration mismatch (that they have no common group for PFS). We usually expect configuration mismatches to show up immediately rather than hours down the line. 

Ideally, the original tunnel setup would have failed. In fact, with IKEv1 where keying IPsec SAs is always done in Quick Mode you get the failure immediately.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 May 2015 13:40:53 +0300

Yoav Nir writes:
> When the tunnel is first set up, it is negotiated in the IKE_AUTH
> exchange. Diffie-Hellman is not performed, so the mismatched
> configuration is not detected - traffic flows through the tunnel.

If your setup is set to that you configure only one Diffie-Hellman for
the IKEv2, which is then used for both IKE SA and Child SAs, then you
would notice this misconfiguration immediately. 

> After a while, one of the gateways attempts to rekey the tunnel, or
> else create a new tunnel with the same peer. This time the tunnel is
> set up using the CREATE_CHILD_SA exchange. The SA payload will
> contain the wrong DH group and the exchange will fail, resulting in
> traffic flow stopping. 

When the last Child SA gets deleted from the IKE SA, you should most
likely shut down the IKE SA, or at least if all the rekeys fails, you
should start from the beginning. 

> As far as I can tell, this behavior is consistent with the RFC, but
> the user experience is very strange. Traffic should either flow or
> not flow - it should not stop at rekeying. 

IKEv2 tries to notice some misconfigurations, but it cannot catch them
all. 

> Am I missing something?

Do not misconfigure your systems...
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 May 2015 15:32:55 +0300

> On May 28, 2015, at 1:40 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Yoav Nir writes:

My product has a separate configuration for phase 1 Diffie-Hellman group and phase 2 Diffie-Hellman group. Thinking it over, I cannot explain why this is needed, but at least StrongSwan also specifies ESP groups separately from IKE groups.

> IKEv2 tries to notice some misconfigurations, but it cannot catch them

IKEv1 caught that particular one.

>> Am I missing something?
> 
> Do not misconfigure your systems…

I’ll tell the users…

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 May 2015 10:21:36 -0400 (EDT)

> My product has a separate configuration for phase 1 Diffie-Hellman group and phase 2 Diffie-Hellman group. Thinking it over, I cannot explain why this is needed, but at least StrongSwan also specif…

I had a long talk with Tero a few IETF's ago, and he was pretty
convincing that it makes no sense whatsoever to have different
phase 1/2 diffie hellman groups.

It does lead to a more complicated exchange. With strongswan, we need to
set the modp group on the esp line to avoid failing if the phase1
negotiates a different modp group depending on the peer, because we will
pick the same modp group in phase2 that we negotiated for phase1.

>>> not flow - it should not stop at rekeying.

Yes. We ran into that with pfs= as well. We never reject pfs since it is
always better, but then at rekey time, depending on which endpoint
started the rekey, the proposal would be rejected on pfs. So we changed
it to not allow pfs when pfs=no.

>> Do not misconfigure your systems…

Try to tell your webgui developers instead? :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 28 May 2015 17:54:34 +0300

> My product has a separate configuration for phase 1 Diffie-Hellman group 
> and phase 2 Diffie-Hellman group.
> Thinking it over, I cannot explain why this is needed, but at least 
> StrongSwan also specifies ESP groups separately from IKE groups.

This had sense in IKEv1. In IKEv2 separating configuration of DH groups
for IKE and IPsec has much less sense. Note that besides the problem of
misconfiguration, that you've encountered, there is another subtle issue.
If the groups for IKE and IPsec are different, then even if no 
misconfiguration
takes place and all IPsec rekeys run smoothly, we have the situation
that the very first IPsec SA has different level of protection than the 
others
IPsec SAs, because unlike the others the first IPsec SA is created using
IKE DH group, not IPsec DH group.

And here are the reasons why there is little sense to use different DH 
groups
for IKE and IPsec in IKEv2. The very first IPsec SA, created in IKE_AUTH 
exchange
will have the keys derived from the shared secret calculated using DH group 
for IKE.
When doing a rekey it is unlikely that you want to degrade security of new 
SA,
so you shodn't use weaker DH group for the IPsec SA than for the IKE SA.
On the other hand, there is no point to use stronger DH group,
since some (probably substantial) part of data has already beed transferred
over the IPsec SA that is being rekeyed, so why should we protect
the resulting part (that will pass over new IPsec SA) differently?

That's a trade-off for piggy-backing of creating the first IPsec SA,
that was selected when IKEv2 was designed.

> Yoav

Regards,
Valery.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 May 2015 07:57:38 -0700

> phase 1/2 diffie hellman groups.

We actually talked about this during the design of IKEv2, but some people claimed we needed the separation because of different security needs for the two parts. In retrospect, we should have said "even if that's true, it will cause problems". Here is an example of where it causes problems.

> Try to tell your webgui developers instead? :)

That seems to be the easiest way around this protocol mis-design.

--Paul Hoffman