[strongSwan-dev] why DH group NEWHOPE_128 inacceptable ?

[Trump DD]

Hi
I have configured newhope, and enable newhope plugin , but
strongswan 5.5.1 told me DH group NEWHOPE_128 inacceptable

08[IKE] IKE_SA (unnamed)[1] state change: CREATED => CONNECTING
08[CFG] selecting proposal:
08[CFG] an algorithm from private space would match, but peer
implementation is unknown, skipped
08[CFG] no acceptable DIFFIE_HELLMAN_GROUP found
08[CFG] selecting proposal:
08[CFG] no acceptable ENCRYPTION_ALGORITHM found
08[CFG] selecting proposal:
08[CFG] no acceptable DIFFIE_HELLMAN_GROUP found
08[CFG] selecting proposal:
08[CFG] no acceptable PSEUDO_RANDOM_FUNCTION found
08[CFG] selecting proposal:
08[CFG] no acceptable PSEUDO_RANDOM_FUNCTION found
08[CFG] selecting proposal:
08[CFG] no acceptable ENCRYPTION_ALGORITHM found
08[CFG] selecting proposal:
08[CFG] proposal matches
08[CFG] received proposals:
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/NEWHOPE_128,
IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
08[CFG] configured proposals:
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/NEWHOPE_128,
IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_GCM_12_256/PRF_HMAC_SHA2_384/MODP_2048,
IKE:AES_CCM_12_256/PRF_HMAC_SHA2_384/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
08[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048
08[IKE] natd_chunk => 22 bytes @ 0x7fb3c000aa60
08[IKE] 0: 37 6B D6 85 77 7D D8 47 00 00 00 00 00 00 00 00 7k..w}.G........
08[IKE] 16: 2D 4F 5B 4D 01 F4 -O[M..
08[IKE] natd_hash => 20 bytes @ 0x7fb3c000aa40
08[IKE] 0: 42 74 37 46 72 9D A2 0E 16 F5 0B FF ED E5 BD C2 Bt7Fr...........
08[IKE] 16: 78 79 72 91 xyr.
08[IKE] natd_chunk => 22 bytes @ 0x7fb3c000aa60
08[IKE] 0: 37 6B D6 85 77 7D D8 47 00 00 00 00 00 00 00 00 7k..w}.G........
08[IKE] 16: 75 95 1E E3 B8 43 u....C
08[IKE] natd_hash => 20 bytes @ 0x7fb3c000a970
08[IKE] 0: EC 73 F7 79 EE 4D 42 CC 81 BF D6 91 FA 47 58 44 .s.y.MB......GXD
08[IKE] 16: 41 62 62 E1 Abb.
08[IKE] precalculated src_hash => 20 bytes @ 0x7fb3c000a970
08[IKE] 0: EC 73 F7 79 EE 4D 42 CC 81 BF D6 91 FA 47 58 44 .s.y.MB......GXD
08[IKE] 16: 41 62 62 E1 Abb.
08[IKE] precalculated dst_hash => 20 bytes @ 0x7fb3c000aa40
08[IKE] 0: 42 74 37 46 72 9D A2 0E 16 F5 0B FF ED E5 BD C2 Bt7Fr...........
08[IKE] 16: 78 79 72 91 xyr.
08[IKE] received src_hash => 20 bytes @ 0x7fb3c0008cc0
08[IKE] 0: 14 23 FC 58 22 F6 04 D7 9B D7 E9 5D 0A 00 6E 2F .#.X"......]..n/
08[IKE] 16: 2E DA 44 F9 ..D.
08[IKE] received dst_hash => 20 bytes @ 0x7fb3c0009730
08[IKE] 0: 42 74 37 46 72 9D A2 0E 16 F5 0B FF ED E5 BD C2 Bt7Fr...........
08[IKE] 16: 78 79 72 91 xyr.
08[IKE] remote host is behind NAT
08[IKE] DH group NEWHOPE_128 inacceptable, requesting MODP_2048

[Noel Kuntze]

Post by Trump DD
08[CFG] an algorithm from private space would match, but peer
implementation is unknown, skipped

Make sure both sides are configured to send the strongswan vendor id.

[Andreas Steffen]

Which means, add the following entry to /etc/strongswan.conf:

charon {
send_vendor_id = yes
}

Regards

Andreas

Post by Noel Kuntze

Post by Trump DD
08[CFG] an algorithm from private space would match, but peer
implementation is unknown, skipped

Make sure both sides are configured to send the strongswan vendor id.
_______________________________________________
Dev mailing list
https://lists.strongswan.org/mailman/listinfo/dev

[Trump DD]

Thanks for reply

I have enable this options in config file.

Now in IKE phase, NEWHOPE was actived,
But in ESP phase, NEWHOPE was always inactive

I have check config newhope128 for esp phase in both sides:

esp=aes256gcm128-newhope128

what's wrong with my config ?


below is my log files, I have config NEWHOPE_128 for both side

02[CFG] selecting proposal:
02[CFG] proposal matches
02[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ
02[CFG] configured proposals:
ESP:AES_GCM_16_256/NEWHOPE_128/NO_EXT_SEQ,
ESP:CHACHA20_POLY1305_256/NO_EXT_SEQ, ESP:AES_GCM_16_128/NO_EXT_SEQ,
ESP:AES_CCM_16_256/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_384_192/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_512_256/MODP_2048/NO_EXT_SEQ
02[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ


On Fri, Oct 21, 2016 at 7:29 PM, Andreas Steffen

Post by Andreas Steffen
charon {
send_vendor_id = yes
}
Regards
Andreas

Post by Noel Kuntze

Post by Trump DD
08[CFG] an algorithm from private space would match, but peer
implementation is unknown, skipped

Make sure both sides are configured to send the strongswan vendor id.
_______________________________________________
Dev mailing list
https://lists.strongswan.org/mailman/listinfo/dev

--
======================================================================
strongSwan - the Open Source VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

[Noel Kuntze]

Post by Trump DD
02[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ

That's normal. With a certain IKE version (don't remember which),
the DH-Group only is important when rekeying, because the initial setup of
a CHILD_SA doesn't include a DH exchange, it is only done when rekeying
the CHILD_SA.

[Andreas Steffen]

Yes, with IKEv1 a fresh DH exchange is done in the Quick Mode
which derives the ESP keying material.

With IKEv2, the ESP DH parameter will only by used with the
CREATE_CHILD_SA message exchange during rekeying or if multiple
CHILD SAs are installed but not in the initial IKE_AUTH exchange
where the ESP keys for the first CHILD SA are derived from the
IKE DH secret.

Regards

Andreas

Post by Noel Kuntze

Post by Trump DD
02[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ

That's normal. With a certain IKE version (don't remember which),
the DH-Group only is important when rekeying, because the initial setup of
a CHILD_SA doesn't include a DH exchange, it is only done when rekeying
the CHILD_SA.