Hello Mike, you and Martin should start a discussion on how to define an optimum strategy for settling on a common proposal if both sides propose a large choice of transforms. Currently strongSwan just selects its first complete transform which is
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Since your client already sends a Diffie-Hellman factor KEi based on MODP_2048_256 but the chosen proposal is based on MODP_2048, strongSwan rejects the KEi payload with 09[LIB] size of DH secret exponent: 256 bits 09[IKE] DH group MODP_2048_256 inacceptable, requesting MODP_2048 09[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ] which is fully compliant with section 2.7 of RFC 4306 http://tools.ietf.org/html/rfc4306#section-2.7 which says 2.7. Cryptographic Algorithm Negotiation ... Since the initiator sends its Diffie-Hellman value in the IKE_SA_INIT, it must guess the Diffie-Hellman group that the responder will select from its list of supported groups. If the initiator guesses wrong, the responder will respond with a Notify payload of type INVALID_KE_PAYLOAD indicating the selected group. In this case, the initiator MUST retry the IKE_SA_INIT with the corrected Diffie-Hellman group. The initiator MUST again propose its full set of acceptable cryptographic suites because the rejection message was unauthenticated and otherwise an active attacker could trick the endpoints into negotiating a weaker suite than a stronger one that they both prefer. Kind regards Andreas On 14.09.2010 23:13, Mike Belopuhov wrote: > 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]== ====================================================================== 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
