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... Also the speeds are low (around 200 kBit/s), and every single byte transmitted consumes power... > 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. 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. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
