Thanks for your comments Valery. The new version [1] has teh two paragraphs in the security consideration. Yours, Daniel
[1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ On Wed, Jun 27, 2018 at 3:26 AM, Valery Smyslov <[email protected]> wrote: > HI Daniel, > > > > I still think the “NOT RECOMMENDED” wording is a bit confusing. > > I’d suggest to change this para to be more explicit: > > > > As the IV must not repeat for one SA when Counter-Mode ciphers are > > used, Implicit IV as described in this document MUST NOT be used in > > setups with the chance that the Sequence Number overlaps for one SA. > > Multicast as described in [RFC5374], [RFC6407] and > > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > > one secret and thus one SA. As such, Implicit IV may only be used with > Multicast > > if some mechanisms are employed that prevent Sequence Number to overlap > > for one SA, otherwise Implicit IV MUST NOT be used with Multicast. > > > > Regards, > > Valery. > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Daniel > Migault > *Sent:* Tuesday, June 26, 2018 9:11 PM > *To:* Valery Smyslov > *Cc:* Waltermire, David A. (Fed); IPsecME WG > *Subject:* Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 > > > > Hi Valery, > > > > Thanks for the feedback. Here are the update I propose. If that is fine > for everyone, I will update the current draft and publish a new version. > > > > Yours, > > Daniel > > > > On Tue, Jun 26, 2018 at 9:22 AM, Valery Smyslov <[email protected]> > wrote: > > Hi, > > I reviewed the draft and I believe it is almost ready. However, > I think there still are few issues. > > 1. The last para of section 4 says: > > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SA. > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SA. As such, it is NOT RECOMMENDED to use > Implicit IV with Multicast. > > I have three problems with this para. First, I think that this para > should be moved into the Security Considerations section. > > <mglt> > > I am fine having it in the security consideration. Anyone opposed ? > > </mglt> > > > > Second, using RFC 2119 word in the beginning ("As the IV MUST NOT repeat") > seems to be wrong here, since it is not an imperative, it's an explanation > here > (because the preposition "As" is used; note that the draft has already > stated that the > nonce MUST NOT repeat in the beginning of Section 4). > > > > <mglt> > > I think that this address your purpose: > > OLD: > > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SA. > > NEW > > As the IV must not repeat for one SA when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SA. > > > > And last (but not least), > I have some trouble following this para, it seems to me that it is > self-contradicting. > First it says that IIV MUST NOT be used if there is a chance that SN > repeats > (which I fully agree with), then it says that multicast is a prominent > example of this situation (i.e. the situation when SN may repeat, which > I fully agree with too) and finally it concludes that for multicast > IIV is NOT RECOMMENDED (i.e. it SHOULD NOT be used). > In other words it is allowed to use IIV for multicast in some > circumstances, > which in my opinion contradicts with earlier MUST NOT. > Either remove the last sentence, or give more explanation > when it is possible to use IIV for multicast. > > <mglt> > > OK I see your point. The reason is mostly that we had a quite long > explanation we removed because we went to the details of a solution we do > not standardize. I suggest we simply mention that some means are deployed.. > > > > OLD: > > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SA. As such, it is NOT RECOMMENDED to use > Implicit IV with Multicast. > > NEW: > > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SA. As such, it is NOT RECOMMENDED to use > Implicit IV with Multicast, unless deployment specific mechanisms > prevent the IV to repeat are provided. > > </mglt> > > > > > 2. The draft defines IIV for ESP only and forbids to use it for IKEv2. > It was discussed and I believe it is right, but I'd like to see few > words (presumably in the Security Considerations) why IIV > in its current form cannot be used in IKEv2. Something along the lines: > > This document defines three new encryption transforms that use implicit > IV. > Unlike most encryption transforms defined to date, which can be used > for both ESP and IKEv2, these transforms are defined for ESP only and > cannot > be used in IKEv2. The reason is that IKEv2 messages don't contain unique > per-message value, that can be used for IV generation. The Message-ID > field in IKEv2 header is somewhat counterpart of SN field in ESP header, > but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to > repeat, > so there is no an easy way to derive unique IV from IKEv2 header fields. > > > > <mglt> > > I am fine adding the text in the draft. > > </mglt> > > > Regards, > Valery. > > > > This message starts a working group last call (WGLC) on > draft-ietf-ipsecme-implicit-iv-04, which will conclude > > on June 29, 2018 at UTC 23:59. Please review and provide feedback on the > -04 version > > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). > Please indicate if you believe this draft is > > ready for publication or if you have comments that must be addressed > before the draft progresses. > > > > Regards, > > Dave > > > > _______________________________________________ > > 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 > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
