Bug #2051
Updated by Tobias Brunner about 6 years ago
It seems strongswan 5.4.0 can send an IKE proposal transform set that does not specify a DH transform.
the following configuration triggers such a malformed packet:
[...]
authby=secret
keyexchange=ikev2
auto=add
ike=aes128-sha1
esp=aes128-sha1
fragmentation=yes
type=transport
This is parsed by libreswan:
<pre>
| *****parse IKEv2 Transform Substructure Payload:
| last transform: v2_TRANSFORM_NON_LAST (0x3)
| length: 12 (0xc)
| IKEv2 transform type: TRANS_TYPE_ENCR (0x1)
| IKEv2 transform ID: AES_CBC (0xc)
| ******parse IKEv2 Attribute Substructure Payload:
| af+type: IKEv2_KEY_LENGTH (0x800e)
| length/value: 128 (0x80)
| remote proposal 1 transform 0 (ENCR=AES_CBC_128) matches local proposal 1 transform 0
| remote proposal 1 transform 0 (ENCR=AES_CBC_128) matches local proposal 2 transform 0
| remote proposal 1 transform 0 (ENCR=AES_CBC_128) matches local proposal 3 transform 0
| *****parse IKEv2 Transform Substructure Payload:
| last transform: v2_TRANSFORM_NON_LAST (0x3)
| length: 8 (0x8)
| IKEv2 transform type: TRANS_TYPE_INTEG (0x3)
| IKEv2 transform ID: AUTH_HMAC_SHA1_96 (0x2)
| remote proposal 1 transform 1 (INTEG=HMAC_SHA1_96) matches local proposal 1 transform 0
| remote proposal 1 transform 1 (INTEG=HMAC_SHA1_96) matches local proposal 2 transform 0
| remote proposal 1 transform 1 (INTEG=HMAC_SHA1_96) matches local proposal 3 transform 0
| *****parse IKEv2 Transform Substructure Payload:
| last transform: v2_TRANSFORM_LAST (0x0)
| length: 8 (0x8)
| IKEv2 transform type: TRANS_TYPE_PRF (0x2)
| IKEv2 transform ID: PRF_HMAC_SHA1 (0x2)
| remote proposal 1 transform 2 (PRF=HMAC_SHA1) matches local proposal 1 transform 0
| remote proposal 1 transform 2 (PRF=HMAC_SHA1) matches local proposal 2 transform 0
| remote proposal 1 transform 2 (PRF=HMAC_SHA1) matches local proposal 3 transform 0
| Seeing if local proposal 1 matched
</pre>
Note the lack of DH transform.
I suspect there is code re-use for PFS in CREATE_CHILD_SA that is allowed to skip PFS by specifying no DH that is accidentally re-used in the Initial Exchanges where this is obviously not allowed.
There might be an additional bug if strongswan itself accepts this kind of malformed proposal.
the following configuration triggers such a malformed packet:
[...]
authby=secret
keyexchange=ikev2
auto=add
ike=aes128-sha1
esp=aes128-sha1
fragmentation=yes
type=transport
This is parsed by libreswan:
<pre>
| *****parse IKEv2 Transform Substructure Payload:
| last transform: v2_TRANSFORM_NON_LAST (0x3)
| length: 12 (0xc)
| IKEv2 transform type: TRANS_TYPE_ENCR (0x1)
| IKEv2 transform ID: AES_CBC (0xc)
| ******parse IKEv2 Attribute Substructure Payload:
| af+type: IKEv2_KEY_LENGTH (0x800e)
| length/value: 128 (0x80)
| remote proposal 1 transform 0 (ENCR=AES_CBC_128) matches local proposal 1 transform 0
| remote proposal 1 transform 0 (ENCR=AES_CBC_128) matches local proposal 2 transform 0
| remote proposal 1 transform 0 (ENCR=AES_CBC_128) matches local proposal 3 transform 0
| *****parse IKEv2 Transform Substructure Payload:
| last transform: v2_TRANSFORM_NON_LAST (0x3)
| length: 8 (0x8)
| IKEv2 transform type: TRANS_TYPE_INTEG (0x3)
| IKEv2 transform ID: AUTH_HMAC_SHA1_96 (0x2)
| remote proposal 1 transform 1 (INTEG=HMAC_SHA1_96) matches local proposal 1 transform 0
| remote proposal 1 transform 1 (INTEG=HMAC_SHA1_96) matches local proposal 2 transform 0
| remote proposal 1 transform 1 (INTEG=HMAC_SHA1_96) matches local proposal 3 transform 0
| *****parse IKEv2 Transform Substructure Payload:
| last transform: v2_TRANSFORM_LAST (0x0)
| length: 8 (0x8)
| IKEv2 transform type: TRANS_TYPE_PRF (0x2)
| IKEv2 transform ID: PRF_HMAC_SHA1 (0x2)
| remote proposal 1 transform 2 (PRF=HMAC_SHA1) matches local proposal 1 transform 0
| remote proposal 1 transform 2 (PRF=HMAC_SHA1) matches local proposal 2 transform 0
| remote proposal 1 transform 2 (PRF=HMAC_SHA1) matches local proposal 3 transform 0
| Seeing if local proposal 1 matched
</pre>
Note the lack of DH transform.
I suspect there is code re-use for PFS in CREATE_CHILD_SA that is allowed to skip PFS by specifying no DH that is accidentally re-used in the Initial Exchanges where this is obviously not allowed.
There might be an additional bug if strongswan itself accepts this kind of malformed proposal.