Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
Thanks for the response and the reference. The Security Considerations referred to 4086, but I thought that it would be useful to add the reference from the nist. I have added the following sentence. """ In addition [SP-800-90A-Rev-1] provides appropriated guidances to build random generators based on deterministic random functions. """ I believe that we do not necessarily need to go into more details that are related to specific transforms, but I am happy to hear otherwise. Yours, Daniel On Mon, Nov 2, 2020 at 9:00 AM Tero Kivinen wrote: > Daniel Migault writes: > > > > 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. > > > > > > Looks ok. > > > 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. > > > > > > 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. > > > > That method is very common piece used when you are making random > number generator. It is for example part of the NIST AES Counter mode > based generator, but to properly make random number generator out of > that need bit more stuff around it. For example you need to make sure > it is rekeyed before the counter rolls over, and of course it is only > as secure as the random secret key you are using to seed it etc. > > See NIST SP 800-90A REv 1 [1] CTR_DRBG description for more > information. > > [1] https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final > -- > kivi...@iki.fi > -- Daniel Migault Ericsson ___ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
Daniel Migault writes: > > 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. > > Looks ok. > 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. > > > 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. > That method is very common piece used when you are making random number generator. It is for example part of the NIST AES Counter mode based generator, but to properly make random number generator out of that need bit more stuff around it. For example you need to make sure it is rekeyed before the counter rolls over, and of course it is only as secure as the random secret key you are using to seed it etc. See NIST SP 800-90A REv 1 [1] CTR_DRBG description for more information. [1] https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final -- kivi...@iki.fi ___ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
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 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". > 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. > > > 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. > > > > > > 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. > 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. > -- > kivi...@iki.fi > -- Daniel Migault Ericsson ___ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
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. > > > 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
Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
Hi Scott, Thank you very much for the review. The review was extremely useful and I believe the text has been updated accordingly. Please find below more details on the updates. Yours, Daniel On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) wrote: > Comments: > > > >- I have issues with the draft’s emphasis on fixed SPI values. One >reason for the SPI value is to handle key updates cleanly; during the >transition, the SPI can be used to indicate whether the packet was >encrypted with the previous set of key or the new ones. As we really don’t >want to discourage rekeying I would suggest that, instead of talking so >much about fixed SPIs, you instead address how to do nonrandom SPIs (for >example, by having the top 3 bytes of the inbound SPI being the SAD entry, >and the lower byte being the rekey index). > > Thanks, the use of a fixed SPI is an extreme case, we may have focused a bit too much. We now provide more generic text where the number of SPIs could be limited but not necessarily limited to 1. We also include the ability to handle rekey to be considered when limiting the number of SPIs. I found this idea very nice thanks! In addition, to the SPI section we also re-inforced the need to manage the keys in the security consideration section and the necessity to rekey. Here is the current text: SPI section has been updated as follows: """ However, for some constrained nodes, generating and handling 32 bit random SPI may consume too much resource, in which case SPI can be generated using predictable functions or end up in a using a subset of the possible values for SPI. In fact, the SPI does not necessarily need to be randomly generated. A node provisioned with keys by a third party - e.g. that does not generate them - and that uses a transform that does not needs random data may not have such random generators. However, non random SPI and restricting their possible values MAY lead to privacy and security concerns. As a result, this alternative should be considered for devices that would be strongly impacted by the generation of a random SPI and after understanding the privacy and security impact of generating non random SPI. When a constrained node limits the number of possible SPIs this limit should both consider the number of inbound SAs - possibly per IP addresses - as well as the ability for the node to rekey. SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the SAD entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. """ 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. When a node generates its key or when random value such as nonces are generated, the random generation MUST follow [RFC4086]. """ > >- >- “Values 0-255 SHOULD NOT be used.”; shouldn’t that be MUST NOT? Can >you think of an advantage a device might have for using a SPI in that >region? > > We mentioned SHOULD NOT in order to preserve the future usage - if ever these values would be allocated. MUST NOT seems more appropriated and we did not have any other reasons for a SHOULD NOT. This has been changed into the new version. > >- > > 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. > 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
Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
Thanks Scott for the comment. I will address them tomorrow, I am just sharing the review to the lwig list. Yours, Daniel On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) wrote: > Comments: > > > >- I have issues with the draft’s emphasis on fixed SPI values. One >reason for the SPI value is to handle key updates cleanly; during the >transition, the SPI can be used to indicate whether the packet was >encrypted with the previous set of key or the new ones. As we really don’t >want to discourage rekeying I would suggest that, instead of talking so >much about fixed SPIs, you instead address how to do nonrandom SPIs (for >example, by having the top 3 bytes of the inbound SPI being the SAD entry, >and the lower byte being the rekey index). >- “Values 0-255 SHOULD NOT be used.”; shouldn’t that be MUST NOT? Can >you think of an advantage a device might have for using a SPI in that >region? > > 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. > >- SN based on clocks; one issue that is not addressed is that standard >receivers are tuned for an increment of one-per-packet; if the sender uses >increments significantly larger than that, and packets are reordered, the >receiver is more likely to reject valid packets because they fell outside >the window. >- One issue you do not address (but I believe you should) is the fact >that some cryptographical transforms are more resilient for key reuse (e.g. >because you use a fixed key, and don’t change it after a reboot) than >others. In particular, both GCM and ChaCha20-Poly1305 have real problems >when that happens, and should be avoided. > > > > Typos: > >- a random SPI may consume to much -> too much >- fix SPI -> fixed SPI >- can be alleviate -> can be alleviated >- algorythm -> algorithm >- > > ___ > IPsec mailing list > ip...@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
