Daniel Migault writes: > The security consideration has been updated as follows: > > """ > The security of a communication provided by ESP is closely related to > the security associated to the management of that key. This usually > include mechanisms to prevent a nonce to repeat for example. When a > node is provisioned with a session key that is used across reboot, > the implementer MUST ensure that the mechanisms put in place remain > valid across reboot as well. > > It is RECOMMENDED to use ESP in conjunction of key management > protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 > [RFC7815]. Such mechanisms are responsible to negotiate fresh > session keys as well as prevent a session key being use beyond its > life time. When such mechanisms cannot be implemented and the > session key is, for example, provisioned, the nodes SHOULD ensure > that keys are not used beyond their life time and that the > appropriated use of the key remains across reboots.
Why the last sentence has SHOULD and not MUST? If device reuses the key across reboots and the algorithm is counter mode based, this will cause serious security issues. Also same thing happens if the counters are allowed to roll over. I would suggest changing that "MUST ensure". > The use of fix SPI MUST NOT be considered as a way to avoid strong random > generators. Such generator will be required in order to provide strong > cryptographic protection”; actually, if the IPsec implementation doesn’t > actually generate its own keys (that is, it relies on an external service > to provide them), and the transform itself doesn’t require random data > (CBC can be implemented securely without one), then the IPsec > implementation doesn’t actually need an CSPRNG. > > <mglt> > The current text presented it in another way. The former text seems to explain > that random was necessary for the generation of SPI. The current text has been > updated to explain that we may have nodes without random generators. > > I am wondering how the IV is generated with CBC without random generator. Normally you use just counter, and encrypt it with secret key. The IV in CBC does not be random, it needs to be unpredictable and it should not be direct counter or other source with low Hamming distance between successive IVs. Actually the problem with old way of CBC mode was that the IV was random, but predictable as implementations used last block of previous packet. If attacker does not know the key you are using to encrypt the counter to generate IVs, the IVs will be unpredictable and random. -- kivi...@iki.fi _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
