I am using strongswan with openssl plugin for IKEv2 Tunnel Set up and using encr_null as encryption algo and hmac_sha1_96 as integrity algo. I have taken the SK_ai and SK_ar value from /var/log/messages file and put them in IKEv2 decryption table entry. But After applying these keys I am getting Malformed Packet... Any Help on this note.. asked 13 Mar '15, 05:42  ssam edited 13 Mar '15, 05:43 showing 5 of 8 show 3 more comments |
One Answer:
While using NULL encryption for IKEv2 is explicitly prohibited by RFC 7296 and the errata for RFC 4307 strongSwan still allows you to negotiate it (could be considered a test feature). It only works if both peers explicitly configure Now, the reason why Wireshark fails to properly decrypt the IKEv2 packets is because until recently the IV length for NULL encryption was incorrectly set to 1 instead of 0. That bug was fixed recently (in the context of strongSwan's userland IPsec implementation). Please refer to the bug report for details and the fix. answered 17 Mar '15, 09:26  ecdsa edited 17 Mar '15, 10:05 |
Sounds like a bug, but a sample capture would be helpful. Could you share one through CloudShark for instance?
There is no NULL encryption for IKEv2 (SK_ai/ar are the IKE keys). There is NULL encryption for ESP, but that is usually handled by the kernel, not strongSwan. Or are you using strongSwan with libipsec?
@Jaap Follow this link for pcap file and respective information https://drive.google.com/folderview?id=0B5IZZ3AygXkySU9pSERUeng4TjA&usp=drive_web Responder_strongswan.txt,Initiator_strongswan.txt are Strongswan log files. Responder_strongswan.txt file contains SK_ai : 72DB46A58D30EF896E4C63FA4945A6E9DD50FD6C SK_ar : C9128B0C4BC40862D2576B74B176055EC2246990
@ecdsa There is ENCR_NULL with ID 11 for IKEv2 Check rfc 5996 & 2410. I am using Strongswan as Initiator and Responder and since Strongswan does not directly support NULL Encryption, I have used openssl plugin for that in Strongswan.
ENCR_NULL may only be negotiated for ESP (which RFC 2410 is all about), not for IKE. In section 5 of RFC 7296 you find the following: "Though the security of negotiated Child SAs does not depend on the strength of the encryption and integrity protection negotiated in the IKE SA, implementations MUST NOT negotiate NONE as the IKE integrity protection algorithm or ENCR_NULL as the IKE encryption algorithm."
@ecdsa I completely agree with your point regarding the security consideration of IKEv2. But IKEv2 gives you provision to use that and I guess probably the reason may be for basic level testing purposes where encryption-decryption is not so important and both party well aware about that. Now, wireshak also have that provision to decrypt a packet having ENCR_NULL as IKEv2 encryption algo, since it has, it should work properly or the option should be dropped.
"But IKEv2 gives you provision to use that", I guess you refer to strongSwan. I wasn't aware that this is not explicitly prevented and actually negotiable (and I'm of the devs :). Anyway, see my answer for details.
Yes I was referring Strongswan... Even I from devs:) don't worry..;) Thanks for refering the bug.. after updating to Version 1.12.4 .. it is working fine..previously I was using Version 1.12.1..