Project

General

Profile

Bug #2557

Incorrect handling of unknown transform types in proposals

Added by CJ Tjhai almost 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
libstrongswan
Target version:
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 whereby moon (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:
  1. PROPOSAL 1: aes256gcm16-sha256-ecp384
  2. PROPOSAL 2: aes256gcm16-sha256-ecp521
The peer sun sends the following IKE proposals, where the first proposal contains an unknown transform type:
  1. PROPOSAL 1: aes256gcm16-sha256-ecp384-unknown_transform_type_247_id_2052
  2. 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]

ikev2_send_unknown_transform.sh (1.01 KB) ikev2_send_unknown_transform.sh Bash script to send IKE_SA_INIT containing an unknown transform type. CJ Tjhai, 22.02.2018 17:32

Associated revisions

Revision b53eb857
Added by Tobias Brunner over 2 years ago

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.

History

#1 Updated by Tobias Brunner almost 3 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 3 years ago

Hi Tobias,

Many thanks for the patch. Yes, they work for us.

Cheers,
CJ

#3 Updated by Tobias Brunner over 2 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 over 2 years ago

Thanks for testing. Merged to master.

Also available in: Atom PDF