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 <daniel.miga...@ericsson.com> > 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 <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > Hi, Paul > > On 10 Jun 2016, at 5:42 AM, Paul Wouters <p...@nohats.ca > <mailto:p...@nohats.ca>> 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 > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
