[strongSwan] Charon fails when MODP_2048_256 is advertised first

Wed Sep 15 08:52:09 CEST 2010

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
> <andreas.steffen at strongswan.org> 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                         andreas.steffen at strongswan.org
>> 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                         andreas.steffen at strongswan.org
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]==