[strongSwan] Charon fails when MODP_2048_256 is advertised first

[Mike Belopuhov]

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
>
>  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
>