Issue #282
esp=aes256-sha256-modp768
Description
Hi,
I have a requirement to setup ipsec using ESP with aes256 and AH with sha256 or better one.
I am able to establish ipsec using aes256-sha1-modp768! but not with aes256-sha256-modp768!
I have setup a host-host connection as shown below.
Machine 10.201.5.137 details
conn host-host
left=10.201.5.137
right=10.201.5.136
esp=aes256-sha256-modp768!
ike=aes256-sha256-modp768!
auto=add
authby=psk
Machine 10.201.5.136 details
conn host-host
left=10.201.5.136
right=10.201.5.137
esp=aes256-sha256-modp768!
ike=aes256-sha256-modp768!
auto=add
authby=psk
When i run ipsec up host-host i see the following
initiating IKE_SA host-host1 to 10.201.5.136
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 10.201.5.137500 to 10.201.5.136500
received packet: from 10.201.5.136500 to 10.201.5.137500
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
authentication of '10.201.5.137' (myself) with pre-shared key
establishing CHILD_SA host-host
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 10.201.5.1374500 to 10.201.5.1364500
received packet: from 10.201.5.1364500 to 10.201.5.1374500
parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP) N(NO_ADD_ADDR) N(NO_PROP) ]
authentication of '10.201.5.136' with pre-shared key successful
IKE_SA host-host1 established between 10.201.5.137[10.201.5.137]...10.201.5.136[10.201.5.136]
scheduling reauthentication in 10073s
maximum IKE_SA lifetime 10613s
received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA
Can you please help me in solving the issue?
Thanks & Regards,
Dinesh
History
#1 Updated by Dinesh Kolli over 12 years ago
My kernel version is 2.6.18-308
#2 Updated by Martin Willi over 12 years ago
Linux 2.6.18 does not support standardized SHA256 HMACs truncated to 128 bit. You can, however, use the proprietary "sha256_96" algorithm instead using truncation to 96 bit.
There is no official algorithm assigned by IANA for 96 bit truncation, hence you'll have to set charon.send_vendor_id strongswan.conf option on both ends to negotiate it. Alternatively update to at least a 2.6.33 kernel to get standardized SHA256 HMAC support using 128 bit truncation.
Using SHA2 does not make much sense with your proposal, though, as MODP768 is by far the weakest algorithm in your combination.
#3 Updated by Dinesh Kolli over 12 years ago
Hi Martin,
Thanks a lot for the reply.
I have another query.
I am able to setup tunnel with aes256-aesxcbc-modp2048! with my kernel version.
How strong is aesxcbc?
Can you please suggest us can we proceed with the above mentioed configuration?
Regards,
Dinesh
#4 Updated by Martin Willi over 12 years ago
- Status changed from New to Closed
How strong is aesxcbc?
It uses AES128 and there are no known weaknesses in this algorithm, so I'd consider it safe (comparable to SHA1 HMACs). But you'll have to decide yourself what is good enough, refer to RFC 3566 and its references for a starting point.
#5 Updated by Dinesh Kolli over 12 years ago
Hi Martin,
Thanks a lot for the information.
Regards,
Dinesh
#6 Updated by Andreas Steffen over 12 years ago
- Tracker changed from Bug to Issue
- Assignee changed from Dinesh Kolli to Martin Willi