Hi Yoav, You are right. Would the word "generate" more appropriated ?
OLD: 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. NEW: This document defines how to generate 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 BR, Daniel On Wed, Jun 15, 2016 at 3:56 PM, Yoav Nir <[email protected]> wrote: > Hi, Daniel > > I think since we didn’t go with some of the wild ideas that would allow > implicit IV in CBC, the verb “compute” here is somewhat confusing. We’re > pretty much just copying the sequence number. “Compute” implies something a > bit more CPU intensive. > > Yoav > > On 15 Jun 2016, at 10:50 PM, Daniel Migault <[email protected]> > wrote: > > 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 > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
