Hmm, my point is a bit different: both MODP_2048_256 and MODP_2048 *are* on the lists of configured and received proposals (third line in the configured proposals actually lists MODP_2048_256) but it's not only discarded in the favor of MODP_2048 but Charon also fires an error.
Or maybe your point is that Charon will try to renegotiate if first configured proposal doesn't fit? In this case it's strange because received proposal contains multiple choices to pick from. I'm aware of "ike=" option, but I'm trying to make our ikev2 daemon work with charon without specifying ike_sa and child_sa transformations. Thanks, Mike On Tue, Sep 14, 2010 at 8:57 PM, Andreas Steffen <[email protected]> wrote: > Hi Mike, > > actually the first configured proposal is > > IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, > > and this is what is selected since the received proposals allow > for this combination. If you want to enforce a specific proposal > then please use the strict character '!' on the initiator side > as in > > ike=aes128-sha256-modp2048s256! > > Kind regards > > Andreas > > 09[CFG] received proposals: > IKE:AES_CBC_256/AES_CBC_192/AES_CBC_128/3DES_CBC/ > HMAC_SHA2_256_128/HMAC_SHA1_96/HMAC_MD5_96/ > PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/PRF_HMAC_MD5/ > MODP_2048_256/MODP_2048/MODP_1536/MODP_1024 > > 09[CFG] configured proposals: > > IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, > > IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536, > IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/ > AES_XCBC_96/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_MD5_96/ > HMAC_SHA2_384_192/HMAC_SHA2_512_256/ > PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/PRF_HMAC_MD5/ > PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/ > MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/ > ECP_256/ECP_384/ECP_521/ECP_224/ECP_192/MODP_4096/MODP_8192/ > MODP_1024/MODP_1024_160 > > On 09/14/2010 08:37 PM, Mike Belopuhov wrote: >> >> Hi, >> >> I'm experiencing a problem that Charon doesn't accept MODP_2048_256 >> DH group if it was listed first in the proposal: >> >> 09[CFG] selecting proposal: >> 09[CFG] proposal matches >> 09[CFG] received proposals: IKE:AES_CBC_256/AES_CBC_192/AES_CBC_128/ >> 3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA1_96/HMAC_MD5_96/PRF_HMAC_SHA2_256/ >> PRF_HMAC_SHA1/PRF_HMAC_MD5/MODP_2048_256/MODP_2048/MODP_1536/MODP_1024 >> 09[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/ >> MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536, >> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/AES_XCBC_96/HMAC_SHA1_96/ >> HMAC_SHA2_256_128/HMAC_MD5_96/HMAC_SHA2_384_192/HMAC_SHA2_512_256/ >> PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/PRF_HMAC_MD5/ >> PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/MODP_2048/MODP_2048_224/MODP_2048_256/ >> MODP_1536/ECP_256/ECP_384/ECP_521/ECP_224/ECP_192/MODP_4096/MODP_8192/ >> MODP_1024/MODP_1024_160 >> 09[CFG] selected proposal: >> IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 >> 09[LIB] size of DH secret exponent: 256 bits >> 09[IKE] DH group MODP_2048_256 inacceptable, requesting MODP_2048 >> >> If I specify it after MODP_2048, then it works as expected: >> >> 09[CFG] selecting proposal: >> 09[CFG] proposal matches >> 09[CFG] received proposals: IKE:AES_CBC_256/AES_CBC_192/AES_CBC_128/ >> 3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA1_96/HMAC_MD5_96/PRF_HMAC_SHA2_256/ >> PRF_HMAC_SHA1/PRF_HMAC_MD5/MODP_2048/MODP_2048_256/MODP_1536/MODP_1024 >> 09[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/ >> MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536, >> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/AES_XCBC_96/HMAC_SHA1_96/ >> HMAC_SHA2_256_128/HMAC_MD5_96/HMAC_SHA2_384_192/HMAC_SHA2_512_256/ >> PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/PRF_HMAC_MD5/ >> PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/MODP_2048/MODP_2048_224/MODP_2048_256/ >> MODP_1536/ECP_256/ECP_384/ECP_521/ECP_224/ECP_192/MODP_4096/MODP_8192/ >> MODP_1024/MODP_1024_160 >> 09[CFG] selected proposal: >> IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 >> 09[LIB] size of DH secret exponent: 2047 bits >> >> "DH secret exponent" sizes are different, while they are >> supposed to be the same. >> >> I'm running strongswan 4.4.1 on 2.6.35 kernel, openssl version >> 0.9.8k-7ubuntu8. >> >> Could you please advise if this behaviour is intentional and >> if so, why it fails to use MODP_2048_256? >> >> Thanks in advance, >> Mike > > ====================================================================== > Andreas Steffen [email protected] > strongSwan - the Linux VPN Solution! www.strongswan.org > Institute for Internet Technologies and Applications > University of Applied Sciences Rapperswil > CH-8640 Rapperswil (Switzerland) > ===========================================================[ITA-HSR]== > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
