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) <sfluh...@cisco.com>
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).
>
> <mglt>
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].
"""
</mglt>
>
> -
> - “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?
>
> <mglt>
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.
</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.
</mglt>
>
> - 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.
>
> <mglt>
We have added this. As suggested by Valery, we also added some text
regarding ESN in the case clock is being used for SN.
</mglt>
>
> -
> - 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.
>
> <mglt>
This is correct we added some text and recommended that in these cases
AES-GCN-SIV may be used.
The following text has been added in the Cryptographic suite section.
"""
2. Resilience to nonce re-use: Some transforms -including AES-GCM -
are very sensitive to nonce collision with a given key. While
the generation of the nonce may prevent such collision during a
session, the mechanisms are unlikely to provide such protection
across reboot. This causes an issue for devices that are
configured with a key. When the key is likely to be re-used
across reboots, it is RECOMMENDED to consider transforms that are
nonce misuse resistant such as AES-GCM-SIV for example[RFC8452]
"""
</mglt>
>
> -
>
>
> Typos:
>
> - a random SPI may consume to much -> too much
> - fix SPI -> fixed SPI
> - can be alleviate -> can be alleviated
> - algorythm -> algorithm
> -
>
> <mglt>
fixed
</mglt>
>
> -
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
--
Daniel Migault
Ericsson
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
