Hi Paul, I hope this has been clarified. In order to clarify this I updated the text in the intro:
OLD: This document defines how to compute the nonce locally when it is implicit. It also specifies how to negotiate this behavior within the Internet Key Exchange version 2 (IKEv2 - RFC7296). NEW: This document defines how to compute the nonce locally when it is implicit. It also specifies how peers agree with Internet Key Exchange version 2 IKEv2 on using an implicit IV versus an explicit IV Please let us know if that address your purpose. BR, Daniel On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir <[email protected]> wrote: > 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 >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
