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 <[email protected]> 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 > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
