Project

General

Profile

Feature #2526

Previously negotiated DH group should preferrably be used for the KE payload during rekeyings

Added by Jacek KoĊ›ciow over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
Due date:
Estimated time:
Resolution:
Fixed

Description

It has been found that wrong DH group is used for the KE payload in the first CREATE_CHILD_SA request at each rekeying (and create of new Child SA pair). Instead of the negotiated DH group, the preferred DH group from the configuration is used.

The consequence is two CREATE_CHILD_SA exchanges for each IKE SA rekeying if the preferred DH group is not supported/used by the peer. The same goes for Child SA rekeying, and create of new Child SA pair, in case of Perfect Forward Secrecy (PFS).

If for example:
- Strongswan is configured with DH group 19 (256-bit random ECP group) and 14 (2048-bit MODP Group).
- Peer supports/is configured with DH group 14 (2048-bit MODP) only.
The IKE SA is established with DH group 14 (after an attempt with DH group 19 and INVALID_KE_PAYLOAD, if Strongswan is the initiator).
If IKE SA rekeying is initiated by Strongswan, the KE payload in the first CREATE_CHILD_SA request is based on DH group 19.
The peer respond with INVALID_KE_PAYLOAD, and new CREATE_CHILD_SA request based on DH 14 must be sent to successfully rekey the IKE SA.
The same thing happen if Child SA rekeying initiated by Strongswan in case of PFS. The KE payload in the first CREATE_CHILD_SA request is based on DH group 19, and a second CREATE_CHILD_SA exchange is needed to successfully rekey the Child SA pair.

This behaviour is not according to RFC7296. The following statement exist in section 1.3 The CREATE_CHILD_SA Exchange:
The Diffie-Hellman group of the KEi MUST be an element of the group the initiator expects the responder to accept (additional Diffie-Hellman groups can be proposed).

The only DH group the initiator can expect the responder to accept is the negotiated DH group.

It is worth mentioning that both Juniper and Cisco use negotiated DH group in the KE payload at rekeying.

Suggested solution is to store last negotiated DH group (for IKE and Child) for peer and use it instead of the one from configuration.

Associated revisions

Revision bb58dfb9
Added by Tobias Brunner over 2 years ago

Merge branch 'dh-group-rekey'

These changes improve rekeying after the peer initially selected a
different DH group than we proposed. Instead of using the configured DH
group again, and causing another INVALID_KE_PAYLOAD notify, we now reuse
the previously negotiated group. We also send the selected DH group
first in the proposals (and move proposals that don't contain the group
to the back) so that implementations that select the proposal first and
without consulting the KE payload (e.g. strongSwan when preferring the
client's proposals) will see the preferred group first.

Fixes #2526.

History

#1 Updated by Tobias Brunner over 2 years ago

  • Tracker changed from Issue to Feature
  • Subject changed from Noncompliance with RFC7296: configured DH group is used for the KE payload in the first CREATE_CHILD_SA instead of last negotiated one to Previously negotiated DH group should preferrably be used for the KE payload during rekeyings
  • Status changed from New to Feedback

Instead of the negotiated DH group, the preferred DH group from the configuration is used.

Well, the DH group is negotiated during the CREATE_CHILD_SA exchange (not beforehand as you make it out, I guess you refer to the DH group negotiated for the IKE_SA). The proposals sent are currently simply based on the configuration and the first DH group in the first proposal is used for the KE payload.

The same thing happen if Child SA rekeying initiated by Strongswan in case of PFS.

However, the DH group negotiated for the IKE_SA has nothing directly to do with the DH group negotiated for CHILD_SAs (or the rekeying of the CHILD_SA created with the IKE_AUTH exchange). But once a CHILD_SA has been established with a CREATE_CHILD_SA exchange its rekeyings could probably be improved by selecting the same DH group that was negotiated previously.

This behaviour is not according to RFC7296. The following statement exist in section 1.3 The CREATE_CHILD_SA Exchange:
The Diffie-Hellman group of the KEi MUST be an element of the group the initiator expects the responder to accept (additional Diffie-Hellman groups can be proposed).

While the behavior is not ideal, it is definitely not non-compliant. "expects" is quite vague, the initiator of the exchange can always claim it expected the peer to accept whatever it proposed (it's not the same as being certain that the responder will only accept the proposed group, then we wouldn't need the INVALID_KE_PAYLOAD notify in the first place). It's exactly why an explanation of how this ambiguity is resolved with the INVALID_KE_PALOAD notify follows right after the quote above.

The only DH group the initiator can expect the responder to accept is the negotiated DH group.

Maybe in practice but theoretically it could choose a different group (e.g. because hardware acceleration for one algorithm broke and it switched to a different one) and as mentioned above, for the first rekeying of the initial CHILD_SA we definitely don't know which DH group we should use (it would just be an educated guess that the peer would select the same group negotiated for IKE also for the CHILD_SA).

#2 Updated by Tobias Brunner over 2 years ago

  • Target version set to 5.6.2

I've pushed some changes to the 2526-dh-group-rekey branch that address this issue. The previous DH group is used for IKE_SA rekeyings and if a CHILD_SA previously used DH (i.e. never for the CHID_SA created with the IKE_SA) that group is also reused for CHILD_SA rekeyings.

#3 Updated by Tobias Brunner over 2 years ago

  • Category set to libcharon
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

#4 Updated by Tobias Brunner over 2 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF