Bug #2557
Incorrect handling of unknown transform types in proposals
Start date:
22.02.2018
Due date:
Estimated time:
Affected version:
5.6.2
Resolution:
Fixed
Description
Hi,
According to RFC7296, Section 3.3.6 we have:
If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and Transform Attributes to be defined in the future.
However, when StrongSwan receives a proposal containing an unknown transform-type, it ignores the transform type, but it does not consider the proposal to be unacceptable. In other words, StrongSwan does not consider the unknown transform-type as a part of the proposal. Following the paragraph above, I believe this behaviour is non-conformance to RFC7296.
Consider the following scenario wherebymoon (192.168.56.103) is running a version of StrongSwan 5.6.2, and sun (192.168.56.102) sends an IKE_SA_INIT request containing a transform type that moon does not understand. Assume that moon is configured to support the following proposals on IKE:
- PROPOSAL 1:
aes256gcm16-sha256-ecp384 - PROPOSAL 2:
aes256gcm16-sha256-ecp521
sun sends the following IKE proposals, where the first proposal contains an unknown transform type:
- PROPOSAL 1:
aes256gcm16-sha256-ecp384-unknown_transform_type_247_id_2052 - PROPOSAL 2:
aes256gcm16-sha256-ecp521
On receipts of this IKE_SA_INIT request form sun, the peer moon accepts the first proposal, which is incorrect. It should respond with INVALID_KE_PAYLOAD notification suggesting to use ECP_521.
I believe the patch in https://github.com/post-quantum/strongswan/commit/77bd7994bd69d3c9f47f3af9bc80dbbdc090b841 should fix this behaviour in accordance to RFC7296.
I would be grateful to get your feedbacks and let me know if you have any questions.
Best regards,
CJ
The content of /etc/ipsec.conf of moon is shown below:
# ipsec.conf - strongSwan IPsec configuration file
config setup
charondebug="ike 4, lib 4, cfg 4, chd 4, net 4, enc 1"
conn mytunnel
left=192.168.56.103
right=192.168.56.102
authby=secret
rekey=yes
fragmentation=yes
keyexchange=ikev2
ike="aes256gcm16-sha256-ecp384,aes256gcm16-sha256-ecp521!"
esp="aes256gcm16-sha256-ecp521,aes256gcm16-sha256-ecp384!"
auto=add
I use the following bash script, which is also attached, to send an IKE_SA_INIT request with unknown transform type:
#!/bin/bash
if [ $# -lt 4 ]; then
echo
echo "$0 [Transform type] [Transform ID] [Target IPv4] [Target Port]"
echo
exit -1
fi
echo "29dd53c20637db650000000000000000212022080000000000000168220000540200002c010100040300000c01000014800e01000300000802000005030000080400001400000008TT00IIII00000024020100030300000c01000014800e010003000008020000050000000804000015280000680014000037ac957a1e5d046a6b5f43b8bfe952c0626fb12026389a37f152deef97a2707cec9ef31dacb339e64082f439cf88d140f4e0ee23f479b2b74e5f0c82d1416bafca94c1ce41aa65e72b5dc05f225ab8d75b5e75663e411e080e5182aac89acb2229000024dd77090fcfc869fe6c768d50123fc5c8c72f1c1a4548778b905f3aa53dd8a1e82900001c000040046afeccb56b083e09011e051204d5cdb5f1349aac2900001c0000400581643a0fda73440443c0e5c273a5a47403fc2472290000080000402e290000100000402f00020003000400052b0000080000401600000014882fe56d6fd20dbc2251613b2ebe5beb" | sed -e "s/TT/`printf %02x $1 | cut -c 1-2`/" -e "s/IIII/`printf %04x $2 | cut -c 1-4 | xxd -r -p | od -t x2 -An | tr -dc '[:alnum:]'`/" | xxd -r -p | netcat -4 -u $3 $4
StrongSwan 5.6.2 is running on the peer moon with IP address 192.168.56.103 at UDP port 500. In order to mimic sun in sending an unknown transform of type 247 and transform ID of 2052, the following script is executed from the peer sun:
./ikev2_send_unknown_transform.sh 247 2052 192.168.56.103 500 | hexdump -C
and the
tcpdump captured packets are shown below:
16:22:27.009757 IP (tos 0x0, ttl 64, id 40491, offset 0, flags [DF], proto UDP (17), length 388)
192.168.56.102.48592 > 192.168.56.103.isakmp: [udp sum ok] isakmp 2.0 msgid 00000000 cookie 29dd53c20637db65->0000000000000000: parent_sa ikev2_init[I]:
(sa: len=80
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=#20 (type=keylen value=0100))
(t: #2 type=prf id=#5 )
(t: #3 type=dh id=#20 )
(t: #4 type=#247 id=2052 ))
(p: #2 protoid=isakmp transform=3 len=36
(t: #1 type=encr id=#20 (type=keylen value=0100))
(t: #2 type=prf id=#5 )
(t: #3 type=dh id=#21 )))
(v2ke: len=96 group=#20 37ac957a1e5d046a6b5f43b8bfe952c0626fb12026389a37f152deef97a2707cec9ef31dacb339e64082f439cf88d140f4e0ee23f479b2b74e5f0c82d1416bafca94c1ce41aa65e72b5dc05f225ab8d75b5e75663e411e080e5182aac89acb22)
(nonce: len=32 nonce=(dd77090fcfc869fe6c768d50123fc5c8c72f1c1a4548778b905f3aa53dd8a1e8) )
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16430(status))
(n: prot_id=#0 type=16431(status))
(n: prot_id=#0 type=16406(status))
(v2vid: len=16 vid=./.mo..."Qa;..[. 882fe56d6fd20dbc2251613b2ebe5beb)
16:22:27.085526 IP (tos 0x0, ttl 64, id 65029, offset 0, flags [DF], proto UDP (17), length 344)
192.168.56.103.isakmp > 192.168.56.102.48592: [bad udp cksum 0xf373 -> 0x3bef!] isakmp 2.0 msgid 00000000 cookie 29dd53c20637db65->d90489c1dc5da833: parent_sa ikev2_init[R]:
(sa: len=36
(p: #1 protoid=isakmp transform=3 len=36
(t: #1 type=encr id=#20 (type=keylen value=0100))
(t: #2 type=prf id=#5 )
(t: #3 type=dh id=#20 )))
(v2ke: len=96 group=#20 3a759dd205700348ce1aef3390492415d44c226ad3d60bdbf786c1a042d4d6248ac8a4b47d12e328e6f6da29a3947f005a6d0446e22c711e87a4a22ab855ffff5beff6021bfbb17f6e3885bfd50fac31ea9445a939eccb4b49510f3de10b62a6)
(nonce: len=32 nonce=(eda32107ca47e182341d6246976ad0ced9d31dd73aa68d89e7a4e589cbfb2f16) )
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16430(status))
(n: prot_id=#0 type=16431(status))
(n: prot_id=#0 type=16404(status))
(v2vid: len=16 vid=./.mo..."Qa;..[. 882fe56d6fd20dbc2251613b2ebe5beb)
The charon log output of what sun receives and responds with is shown below:
Feb 22 16:22:27 strongswan charon: 03[NET] received packet => 360 bytes @ 0x7faed788a3a0
Feb 22 16:22:27 strongswan charon: 03[NET] 0: 29 DD 53 C2 06 37 DB 65 00 00 00 00 00 00 00 00 ).S..7.e........
Feb 22 16:22:27 strongswan charon: 03[NET] 16: 21 20 22 08 00 00 00 00 00 00 01 68 22 00 00 54 ! "........h"..T
Feb 22 16:22:27 strongswan charon: 03[NET] 32: 02 00 00 2C 01 01 00 04 03 00 00 0C 01 00 00 14 ...,............
Feb 22 16:22:27 strongswan charon: 03[NET] 48: 80 0E 01 00 03 00 00 08 02 00 00 05 03 00 00 08 ................
Feb 22 16:22:27 strongswan charon: 03[NET] 64: 04 00 00 14 00 00 00 08 F7 00 04 08 00 00 00 24 ...............$
Feb 22 16:22:27 strongswan charon: 03[NET] 80: 02 01 00 03 03 00 00 0C 01 00 00 14 80 0E 01 00 ................
Feb 22 16:22:27 strongswan charon: 03[NET] 96: 03 00 00 08 02 00 00 05 00 00 00 08 04 00 00 15 ................
Feb 22 16:22:27 strongswan charon: 03[NET] 112: 28 00 00 68 00 14 00 00 37 AC 95 7A 1E 5D 04 6A (..h....7..z.].j
Feb 22 16:22:27 strongswan charon: 03[NET] 128: 6B 5F 43 B8 BF E9 52 C0 62 6F B1 20 26 38 9A 37 k_C...R.bo. &8.7
Feb 22 16:22:27 strongswan charon: 03[NET] 144: F1 52 DE EF 97 A2 70 7C EC 9E F3 1D AC B3 39 E6 .R....p|......9.
Feb 22 16:22:27 strongswan charon: 03[NET] 160: 40 82 F4 39 CF 88 D1 40 F4 E0 EE 23 F4 79 B2 B7 @..9...@...#.y..
Feb 22 16:22:27 strongswan charon: 03[NET] 176: 4E 5F 0C 82 D1 41 6B AF CA 94 C1 CE 41 AA 65 E7 N_...Ak.....A.e.
Feb 22 16:22:27 strongswan charon: 03[NET] 192: 2B 5D C0 5F 22 5A B8 D7 5B 5E 75 66 3E 41 1E 08 +]._"Z..[^uf>A..
Feb 22 16:22:27 strongswan charon: 03[NET] 208: 0E 51 82 AA C8 9A CB 22 29 00 00 24 DD 77 09 0F .Q.....")..$.w..
Feb 22 16:22:27 strongswan charon: 03[NET] 224: CF C8 69 FE 6C 76 8D 50 12 3F C5 C8 C7 2F 1C 1A ..i.lv.P.?.../..
Feb 22 16:22:27 strongswan charon: 03[NET] 240: 45 48 77 8B 90 5F 3A A5 3D D8 A1 E8 29 00 00 1C EHw.._:.=...)...
Feb 22 16:22:27 strongswan charon: 03[NET] 256: 00 00 40 04 6A FE CC B5 6B 08 3E 09 01 1E 05 12 ..@.j...k.>.....
Feb 22 16:22:27 strongswan charon: 03[NET] 272: 04 D5 CD B5 F1 34 9A AC 29 00 00 1C 00 00 40 05 .....4..).....@.
Feb 22 16:22:27 strongswan charon: 03[NET] 288: 81 64 3A 0F DA 73 44 04 43 C0 E5 C2 73 A5 A4 74 .d:..sD.C...s..t
Feb 22 16:22:27 strongswan charon: 03[NET] 304: 03 FC 24 72 29 00 00 08 00 00 40 2E 29 00 00 10 ..$r).....@.)...
Feb 22 16:22:27 strongswan charon: 03[NET] 320: 00 00 40 2F 00 02 00 03 00 04 00 05 2B 00 00 08 ..@/........+...
Feb 22 16:22:27 strongswan charon: 03[NET] 336: 00 00 40 16 00 00 00 14 88 2F E5 6D 6F D2 0D BC ..@....../.mo...
Feb 22 16:22:27 strongswan charon: 03[NET] 352: 22 51 61 3B 2E BE 5B EB "Qa;..[.
Feb 22 16:22:27 strongswan charon: 03[NET] received packet: from 192.168.56.102[48592] to 192.168.56.103[500]
Feb 22 16:22:27 strongswan charon: 03[NET] waiting for data on sockets
Feb 22 16:22:27 strongswan charon: 08[NET] received packet: from 192.168.56.102[48592] to 192.168.56.103[500] (360 bytes)
Feb 22 16:22:27 strongswan charon: 08[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) V ]
Feb 22 16:22:27 strongswan charon: 08[CFG] looking for an ike config for 192.168.56.103...192.168.56.102
Feb 22 16:22:27 strongswan charon: 08[CFG] ike config match: 3100 (192.168.56.103 192.168.56.102 IKEv2)
Feb 22 16:22:27 strongswan charon: 08[CFG] candidate: 192.168.56.103...192.168.56.102, prio 3100
Feb 22 16:22:27 strongswan charon: 08[CFG] found matching ike config: 192.168.56.103...192.168.56.102 with prio 3100
Feb 22 16:22:27 strongswan charon: 08[IKE] received strongSwan vendor ID
Feb 22 16:22:27 strongswan charon: 08[IKE] 192.168.56.102 is initiating an IKE_SA
Feb 22 16:22:27 strongswan charon: 08[IKE] IKE_SA (unnamed)[1] state change: CREATED => CONNECTING
Feb 22 16:22:27 strongswan charon: 08[CFG] selecting proposal:
Feb 22 16:22:27 strongswan charon: 08[CFG] proposal matches
Feb 22 16:22:27 strongswan charon: 08[CFG] received proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_384, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
Feb 22 16:22:27 strongswan charon: 08[CFG] configured proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_384, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
Feb 22 16:22:27 strongswan charon: 08[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_384
Feb 22 16:22:27 strongswan charon: 08[CFG] received supported signature hash algorithms: sha256 sha384 sha512 identity
Feb 22 16:22:27 strongswan charon: 08[IKE] natd_chunk => 22 bytes @ 0x7faeb800b150
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 29 DD 53 C2 06 37 DB 65 00 00 00 00 00 00 00 00 ).S..7.e........
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: C0 A8 38 67 01 F4 ..8g..
Feb 22 16:22:27 strongswan charon: 08[IKE] natd_hash => 20 bytes @ 0x7faeb800a3f0
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 6A FE CC B5 6B 08 3E 09 01 1E 05 12 04 D5 CD B5 j...k.>.........
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F1 34 9A AC .4..
Feb 22 16:22:27 strongswan charon: 08[IKE] natd_chunk => 22 bytes @ 0x7faeb800b150
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 29 DD 53 C2 06 37 DB 65 00 00 00 00 00 00 00 00 ).S..7.e........
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: C0 A8 38 66 BD D0 ..8f..
Feb 22 16:22:27 strongswan charon: 08[IKE] natd_hash => 20 bytes @ 0x7faeb800a3b0
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 5C A3 E2 CE 54 4D F1 A6 0A 83 D4 6D C6 32 4E 27 \...TM.....m.2N'
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 87 B1 64 27 ..d'
Feb 22 16:22:27 strongswan charon: 08[IKE] precalculated src_hash => 20 bytes @ 0x7faeb800a3b0
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 5C A3 E2 CE 54 4D F1 A6 0A 83 D4 6D C6 32 4E 27 \...TM.....m.2N'
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 87 B1 64 27 ..d'
Feb 22 16:22:27 strongswan charon: 08[IKE] precalculated dst_hash => 20 bytes @ 0x7faeb800a3f0
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 6A FE CC B5 6B 08 3E 09 01 1E 05 12 04 D5 CD B5 j...k.>.........
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F1 34 9A AC .4..
Feb 22 16:22:27 strongswan charon: 08[IKE] received src_hash => 20 bytes @ 0x7faeb8005440
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 6A FE CC B5 6B 08 3E 09 01 1E 05 12 04 D5 CD B5 j...k.>.........
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F1 34 9A AC .4..
Feb 22 16:22:27 strongswan charon: 08[IKE] received dst_hash => 20 bytes @ 0x7faeb80060d0
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 81 64 3A 0F DA 73 44 04 43 C0 E5 C2 73 A5 A4 74 .d:..sD.C...s..t
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 03 FC 24 72 ..$r
Feb 22 16:22:27 strongswan charon: 08[IKE] local host is behind NAT, sending keep alives
Feb 22 16:22:27 strongswan charon: 08[IKE] remote host is behind NAT
Feb 22 16:22:27 strongswan charon: 08[IKE] sending strongSwan vendor ID
Feb 22 16:22:27 strongswan charon: 08[IKE] shared Diffie Hellman secret => 48 bytes @ 0x7faeb800c340
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 8E 7D 2A E0 DB 71 94 54 8E 91 69 46 AD 72 0C EF .}*..q.T..iF.r..
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 38 27 1E 28 85 62 07 51 18 D3 1E A0 8C 9A BD 24 8'.(.b.Q.......$
Feb 22 16:22:27 strongswan charon: 08[IKE] 32: E6 58 90 2C FA FC 94 67 41 C5 46 26 E7 D6 B4 B6 .X.,...gA.F&....
Feb 22 16:22:27 strongswan charon: 08[IKE] SKEYSEED => 32 bytes @ 0x7faeb8005480
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 4A D0 64 B1 93 C8 8F 1F 2E 85 B5 E4 34 38 6F 47 J.d.........48oG
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: EB 0A 93 96 6B 29 7A C7 03 70 70 E3 45 A8 B4 78 ....k)z..pp.E..x
Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_d secret => 32 bytes @ 0x7faeb800ad20
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 93 28 6C 4C 45 93 75 45 11 6D A1 EA 12 05 70 A7 .(lLE.uE.m....p.
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F2 4A FE 81 2F 8D 58 89 B6 FF FE 72 72 E9 6A 22 .J../.X....rr.j"
Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_ei secret => 36 bytes @ 0x7faeb800d440
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: B1 35 BB 4F 6D 29 45 0C 8D 57 19 D4 81 11 EC 05 .5.Om)E..W......
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 4C 40 EC E6 41 F8 08 9A CE 80 60 DA F3 2A A8 9E L@..A.....`..*..
Feb 22 16:22:27 strongswan charon: 08[IKE] 32: 4B CD 96 DF K...
Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_er secret => 36 bytes @ 0x7faeb800c340
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 06 48 51 18 C1 05 FD 56 40 F2 6F 99 FB B6 B7 61 .HQ....V@.o....a
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 24 76 5F F9 2A F8 68 8F DC 6D F9 92 64 2D F4 E6 $v_.*.h..m..d-..
Feb 22 16:22:27 strongswan charon: 08[IKE] 32: 1F 62 A6 31 .b.1
Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_pi secret => 32 bytes @ 0x7faeb800d440
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: FB 10 A4 3C 32 7E FD 5B F2 96 E6 DE 6C D9 06 97 ...<2~.[....l...
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 80 C3 7C A9 D9 7E 79 AE F4 2A 96 EA A1 64 E1 EA ..|..~y..*...d..
Feb 22 16:22:27 strongswan charon: 08[IKE] Sk_pr secret => 32 bytes @ 0x7faeb800c340
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 27 07 C3 75 CD 82 24 0A 8E EB DD 97 56 55 09 D0 '..u..$.....VU..
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: F0 69 A5 7C D2 34 CA 7B F9 AF 7B 65 FF C6 3E 8D .i.|.4.{..{e..>.
Feb 22 16:22:27 strongswan charon: 08[CFG] sending supported signature hash algorithms: sha256 sha384 sha512 identity
Feb 22 16:22:27 strongswan charon: 08[IKE] natd_chunk => 22 bytes @ 0x7faeb8009270
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 29 DD 53 C2 06 37 DB 65 D9 04 89 C1 DC 5D A8 33 ).S..7.e.....].3
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: C0 A8 38 67 01 F4 ..8g..
Feb 22 16:22:27 strongswan charon: 08[IKE] natd_hash => 20 bytes @ 0x7faeb8009370
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 2C 50 98 79 A7 8E 7D D1 E1 3C 9E CB A0 13 9F 20 ,P.y..}..<.....
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: B5 AB CF D2 ....
Feb 22 16:22:27 strongswan charon: 08[IKE] natd_chunk => 22 bytes @ 0x7faeb800fec0
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: 29 DD 53 C2 06 37 DB 65 D9 04 89 C1 DC 5D A8 33 ).S..7.e.....].3
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: C0 A8 38 66 BD D0 ..8f..
Feb 22 16:22:27 strongswan charon: 08[IKE] natd_hash => 20 bytes @ 0x7faeb8009370
Feb 22 16:22:27 strongswan charon: 08[IKE] 0: E3 6B D4 DE 63 F9 D7 44 CE 29 BE FC 24 AF 59 71 .k..c..D.)..$.Yq
Feb 22 16:22:27 strongswan charon: 08[IKE] 16: 53 56 4C 83 SVL.
Feb 22 16:22:27 strongswan charon: 08[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) V ]
Feb 22 16:22:27 strongswan charon: 08[NET] sending packet: from 192.168.56.103[500] to 192.168.56.102[48592] (316 bytes)
Feb 22 16:22:27 strongswan charon: 05[NET] sending packet: from 192.168.56.103[500] to 192.168.56.102[48592]
Associated revisions
History
#1 Updated by Tobias Brunner almost 4 years ago
- Status changed from New to Feedback
- Target version set to 5.6.3
Thanks for the report. I agree that the current behavior is not fully compliant with the RFC.
I believe the patch in https://github.com/post-quantum/strongswan/commit/77bd7994bd69d3c9f47f3af9bc80dbbdc090b841 should fix this behaviour in accordance to RFC7296.
I don't think we have to be so restrictive. We just have to make sure to compare all the transform types contained in both proposals. This way we don't have to explicitly change anything if new transform types are added. I pushed patches to this end to the 2557-unknown-transform-types branch. Let me know if these work for you.
#2 Updated by CJ Tjhai almost 4 years ago
Hi Tobias,
Many thanks for the patch. Yes, they work for us.
Cheers,
CJ
#3 Updated by Tobias Brunner almost 4 years ago
- Subject changed from Incorrect handling of unknown transform type to Incorrect handling of unknown transform types in proposals
- Status changed from Feedback to Closed
- Assignee set to Tobias Brunner
- Resolution set to Fixed
#4 Updated by Tobias Brunner almost 4 years ago
Thanks for testing. Merged to master.
Merge branch 'unknown-transform-types'
This changes how unknown transform types are handled in proposals. In
particular we make sure not to accept a proposal if it contains unknown
transform types (they were just ignored previously, which could have
resulted in an invalid selected proposal).
Fixes #2557.