[strongSwan] Charon fails when MODP_2048_256 is advertised first

Mike Belopuhov mkb at crypt.org.ru
Wed Sep 15 16:51:24 CEST 2010

Thanks for a clarification, Andreas!

I've implemented the needed feature in our software.

On Wed, Sep 15, 2010 at 8:52 AM, Andreas Steffen
<andreas.steffen at strongswan.org> wrote:
> 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
> 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

More information about the Users mailing list