Hi Paul,
thank you for your comments.
This draft makes me nervous, as compression has been removed from
encryption specifications in the last few years.
As far as I know IPcomp isn't deprecated, is it?
If you mean TLS, then as far as I understand the compression-related attacks
on TLS rely on an ability for an attacker to insert specific data into the
encrypted (and compressed) stream that contains secret information
(e.g. password). I don't think it's relevant to IKE and it is discussed
in the Security Considerations section.
I find the security
considerations also weak on this. It basically says "if you think
compression might be security issue, don't use it". Which isn't helpful
at all to implementors.
Not really. It says that basically using compression in IKE should be safe.
However, IF you transfer secret information inside an IKE SA and
IF some part of the IKE messages originates outside IKE,
then you are probably at risk. This could happen in case of
EAP authentication using weak EAP methods that transfer
passwords in clear. Note, that RFC 7296 strongly discourage
using such methods.
Note, that this is -00 draft and the security considerations
are currently very basic. What do you think should be added there?
I am also worried about the security of maliciously compressed payloads,
eg a zillion 0's, and other corner cases such as AUTH-NULL clients.
In this case either the decompressor or the message parser will return an error.
Note that malicious peer could send zillion 0's even without using compression.
A robust implementation should handle such cases.
But I think it's a good idea to mention this in the security considerations.
I'm also not yet very convinced about the use case. For instance, the
mentioned explosion of algorithms supported causing big IKE_INIT packets
seems very unlikely for IoT devices which most likely only support 1 or
2 algorithms anyway.
These are two different use cases. For IoT devices the primary benefit
is the decrease of the power consumption. For the others the primary
benefit is avoiding of an IP fragmentation of the IKE_SA_INIT messages
and making IKE Fragmentation less likeky for the rest messages.
Note I'm not strongly against it. I just need more convincing.
I'm trying to convince :-)
Paul
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
