HI Tero,
Valery Smyslov writes:
7. Descriptions for AES-GCM and ENCR_AES_CCM_8 demonstrate some
inconsistency. While the former claims that the advantage of using
shorter than 16 bytes ICV are minimal, the latter claims that
8 bytes ICV is enough for IKE SA. Sure, the latter is for IoT use case,
but I don't expect that the amount of data transferred over IKE SA
in IoT and non-IoT cases is many magnitudes different.
I think some other reasons must be given to justify this selection.
For example: the majority of existing IoT devices implement
ENCR_AES_CCM_8, so we decided to make it mandatory in IKE
(well, I don't know if it is true, I'm not familiar with IoT world).
It matters when you use things like 802.15.9. IEEE 802.15.9 provides a
method to transport IKEv2 messages over IEE Std 802.15.4. In typical
PHY of the 802.15.4 the max frame size is 127 bytes, which leaves
about 96 bytes for the 802.15.9 for payload. Normal 300 byte IKEv2
packet will require about 3-4 fragments sent in 3-4 frames. Each of
those frames will be acknowledged, and there might be timing
constrains how often they can be sent (for example in TSCH network
this might be once per second at max, when using 10ms slot time, and
slotframe size of 100).
If we raise the MAC size from 8 to 16, that will cause 8% probability
that we need one more frame to send that last part...
That's a good reason. Shouldn't this (or similar) explanation be added to the
draft?
Also the speeds are low (around 200 kBit/s), and every single byte
transmitted consumes power...
That's also a valid reason. Again, shouldn't it be mentioned?
13. Section 3.3
There is some disconnect between Sections 3.1 and 3.3. Section 3.1 lists
ENCR_AES_CCM_8 as the only preferred choice for IoT. However,
ENCR_AES_CCM_8 is AEAD cipher, so if it is used then no separate
authentication transform is needed. Why then AUTH_AES_XCBC_96
is listed in Section 3.3 for IoT use case? What encryption transform
it is intended to be used with in IoT?
Because for example 802.15.4 devices use AES_CCM already, thus they do
have hardware to do AES_CCM, but they DO NOT have hardware to to AES
CBC (there is no AES decryption at all in the hardware). Implementing
AEAD is easier as it is just software for IKEv2, than adding AES
decryption to hardware.
I understand that most IoT devices implement AEAD (AEC-CCM).
And in this case there is no need for them to use Integrity Transform at all.
But since the draft explicitely lists an Integrity Transform for use
in IoT world (AUTH_AES_XCBC_96), then some plain (non-AEAD)
Encryption Transform for IoT must also be specified,
so that they can be used together.
On some other IoT devices the situation might be different.
15. Section 3.4
If an attacker can
retrieve the private numbers (for example a, b) (and? or?) the public
values (for example g**a, g**b), then the attacker can compute the
secret and the keys used and decrypt the exchange.
What is (and? or?)? Is it some leftover? Shouldn't it be just "and"?
Actual "or" is right. I.e., if attacker can get either one of the
private numbers, he can compute the secret.
I read this "or" as "if attacker can retrieve private numbers or public values".
The attacker can always retrieve public values, - it is not the threat.
If the phrase is changed as you suggest - "if attacker can retrieve
either one of private numbers" then the phrase makes sense.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
