[strongSwan] Charon fails when MODP_2048_256 is advertised first

[Mike Belopuhov]

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