Overall:
I notice that you are using a construction different from that used
in TLS 1.3, which doesn't directly repeat nonces across associations.
S 2.
This document does not consider AES-CBC ([RFC3602])as AES-CBC
requires the IV to be unpredictable. Deriving it directly from the
packet counter as described below is insecure.
Can you provide a cite for this? In any case, note that there are
straightforward algorithms for deriving a CBC IV from a counter
(e.g., run AES in counter mode with a different key). That structure
would actually be suitable for GCM as well (and would address
my point above).
S 3.
o IV: Initialization Vector. Although security requirements vary,
the common usage of this term implies that the value is
unpredictable.
I don't think that this is true at all. I've frequently heard of a
zero IV. It's also odd in that your IV is in fact predictable.
S 5.
I'm a bit surprised that you are deciding to have duplicate
code points for every algorithm rather than some sort of IKE
negotiation payload. I see that the WG is currently defining
other extensions where you take that approach.
-Ekr
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
