[strongSwan] policy mismatch

[ccsalway]

Windows has got its setup all messed up then… it also offers the weakest ciphers first.  What a pain!  I notice OSX does it correctly though - strongest ciphers offered first.

For the record, the IKE proposals that work for OSX and Windows (with weak or strong ciphers enabled) is as follows

aes256-sha256-prfsha256-modp2048-modp1024


> On 2 May 2018, at 09:05, Tobias Brunner <tobias at strongswan.org> wrote:
> 
> Hi Christian,
> 
>> When Windows connects, strongSwan gives it the wrong policy and hence
>> Windows 10 reports a*policy match error*
>> 
>> May  1 21:53:12 08[CFG] *received proposals*:
>> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
>> IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
>> IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
>> IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
>> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
>> IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
>> IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
>> IKE:AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
>> IKE:AES_CBC_192/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
>> IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
>> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
>> IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
>> IKE:AES_GCM_16_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
>> IKE:AES_GCM_16_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
>> IKE:AES_GCM_16_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
>> IKE:AES_GCM_16_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
>> IKE:AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
>> IKE:AES_GCM_16_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
>> May  1 21:53:12 08[CFG] *configured proposals*:
>> IKE:AES_GCM_16_256/AES_GCM_16_128/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_256/MODP_1024
>> May  1 21:53:12 08[CFG] selected proposal:
>> IKE:*AES_GCM_16_128/PRF_HMAC_SHA2_256/MODP_1024*
>> 
>> Expected response (I'm guessing)
>> *AES_GCM_16_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024 *(although
>> I dont know why it doesnt chose the better ciphers).
> 
> No, with AES-GCM there is no integrity algorithm (HMAC_SHA* here) needed
> as combined-mode ciphers like AES-GCM provide both encryption and
> integrity protection (see section 8 in RFC 5282 [1] and section 3.3 in
> RFC 7296 [2]).
> So the problem is that the client proposes invalid proposals and
> probably expects an invalid proposal back.
> 
> Regards,
> Tobias
> 
> [1] https://tools.ietf.org/html/rfc5282#section-8 <https://tools.ietf.org/html/rfc5282#section-8>
> [2] https://tools.ietf.org/html/rfc7296#section-3.3 <https://tools.ietf.org/html/rfc7296#section-3.3>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180502/997e0017/attachment.html>