Bug ID 723988: IKEv1 phase2 key length can be changed during SA negotiation

Last Modified: Nov 15, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP TMOS(all modules)

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3,,,,, 11.6.4, 11.6.5, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,,,,,,,, 12.1.4,, 12.1.5, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,,,, 13.1.3,,, 14.0.0,,,,,, 14.0.1,

Fixed In:

Opened: Jun 12, 2018
Severity: 4-Minor


Using IKEv1, if phase2 key length does not agree on both sides, a responder accepts whatever the initiator proposes as key length, but only after an initiator is authenticated. This results in key length downgrade or upgrade at a trusted peer's request, because the IKEv1 daemon was configured to obey the other peer's key length request.


The responder accepts AES128 anyway. Although phase1 key length must be an exact match, when phase2 key length does not match, this allows an initiating peer to change the key length a responder uses, thus changing the strength configured by that responder.


The value of the ike-phase2-encrypt-algorithm on both sides agree on the encryption algorithm, but differ in key length. For example, if the initiator picks AES128 when the responder expects AES256.


No workaround is known at this time.

Fix Information

Policy in phase2 negotiation is now changed to require exact match in key length for both initiator and responder, so both sides get the strength explicitly configured for that peer. Now config must be identical on both sides for ike-phase2-encrypt-algorithm inside ipsec-policy.

Behavior Change