Hi Tero, Thanks for the comments. Please find below how I updated the text on my local copy and let me know if that addresses your concerns.
Yours, Daniel On Fri, Oct 30, 2020 at 3:13 PM Tero Kivinen <kivi...@iki.fi> wrote: > 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". > <mglt> Correct. it must be a MUST. I also explicitly added that condition on nonce and counter needs to remain valid. The new text is as follows: When such mechanisms cannot be implemented and the session key is, for example, provisioned, the nodes MUST ensure that keys are not used beyond their life time and that the appropriate use of the key remains across reboots - e.g. conditions on counters and nonces remains valid. </mglt> > > > 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. > <mglt> Thanks for the information. What I was wondering then, is for which reason can't we consider this as a random generator - of a limited lifetime. </mglt> > -- > kivi...@iki.fi > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
