Hi, Paul On 10 Jun 2016, at 5:42 AM, Paul Wouters <[email protected]> wrote:
> On Thu, 9 Jun 2016, Daniel Migault wrote: > >> Please find our new proposal with ESP using implicit IV [1]. We would like >> to present and discuss it at the next IETF meeting. > > I must understand it wrong... > > Aren't these IVs different per ESP packet? And unrelated to IKE > values? How do both parties calculate the IV if it is not send as part > of the packet? > >> From what I understand, only part of that comes from IKE (aka the salt > values that are taken from the IKE KEYMAT). As far as I understand, it > still needs to be unpredictable? > > If this IV somehow comes from IKE, it might be very tricky for FIPS > certifications, because the security of the ESP IV then depends on > the IKE userland. > All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP packet. For all of those algorithms, the respective RFC recommends to use a counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead, but a counter is simpler. ESP already has a counter - the packet sequence. If you follow the advice in the RFCs the ESP header will look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | IV | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- And the Sequence Number and IV fields will hold the exact same number, except that one is 32-bit while the other is 64-bit. Our draft simply negotiates omitting the IV field since it is redundant. Hope this helps Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
