Michael Rossberg writes: > Like pointed out in the answer to Valery’s mail. There are possibly more > issues, as attackers are able to generate new traffic, they can use for > cryptanalysis (see > https://www.aircrack-ng.org/doku.php?id=arp-request_reinjection).
If any of our algorithms are vulnerable to that kind of attacks, we immediately need to move that algorithm to MUST NOT category. None of the modern ciphers should be affected by that. > Having anti-replay guarantees is just a reliable foundation. IMHO the > case of applications being responsible holds just as well for unicast > applications. TCP takes care of that, still no-one honestly discusses > removing replay checks for high volume unicast SAs. Actually there are several complains that people are disabling anti-replay for VPNs just as there are buggy implementations of it, and if you disable it then at least some connections might be more stable... The thing is that you never know whether it is disabled on the receiver or not... > > When using multicast you already need to use SPI, and destination > > address as your SAD lookup (RFC4303, section 2.1), i.e. use option 2 > > there. On the other hand you could use the SPI, destination address, > > and source address to find the replay window and largest sequence > > number used if you want to do anti-replay protection on multicast SAs > > so that each sender has separate replay windows. > > This still requires to know all possible senders beforehand. Also the > SAs will still need to agree on an IV subspace and sending an explicit > IV per packet. Yes, this is similar than your proposal, except it uses standard ESP. I.e., you need to know which sender IDs are to be used, here you need to know which source addresses are used. You also need to transmit Sender ID inplace, in standard ESP you reserve part of IV for that purpose and use that. Note, that if you use SPI, destination address and source address to find the replay protection information you do not need to transmit that part of IV inplace. I.e. the SAD has the 32-bit salt for GCM Nonce + the IV from the packet (whether it is actual transmitted IV, or implicit IV in form of sequence number does not matter). You could simply make multicast SAs in such way that they only have 16-bit random salt per SA, and other 16-bit of the random salt is per sender. This means when multicast SA is created it creates 16-bits of common salt, and then when sender joins the group, it will get unique 16-bits random salt assigned to it. This 16-bit salt part + sequence number + replay window is stored to the list of senders indexed by sender address under the SA. There are most likely also other ways of doing the same thing. Good thing is that we already have the g-ikev2 doing group key management using IKEv2, so we can easily make sure we can do needed negotiations in there. All multicast traffic cases are going to be needing that g-ikev2 anyways, so my proposal is that we move discussion about multicast cases to that g-ikev2 discussion. > Like written already: An unpredictable value of 32bit size is of no > real value from a crypto point of view. One could simply guess the > value and have a realistic chance of being right after a couple of > thousand tries. I believe it is only in the standard, as with 64 bit > sequence numbers there where 32 bits left; needing to be filled. I think it came from the NIST documents where it was called fixed field. The idea was to make sure that even if someone accidently used same key twice for two different SAs, this will not cause issues, as that fixed field is going to be unique anyways. I.e. NIST 800-38D section 8.2.1 says: ---------------------------------------------------------------------- ... The lengths and positions of the fixed field and the invocation field shall be fixed for each supported IV length for the life of the key. In order to promote interoperability for the default IV length of 96 bits, this Recommendation suggests, but does not require, that the leading (i.e., leftmost) 32 bits of the IV hold the fixed field; and that the trailing (i.e., rightmost) 64 bits hold the invocation field. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
